Core components are loaded with PSR-4 but in core/lib/Drupal/

Adding beta deadline. I doubt we'll want to tackle this afterwards.

I actually think core/lib is fine. Semantically, the things in that directory are core libraries. Versus in modules, the stuff in that folder is the actual source code of the module.

Not touching /core/lib has always been part of the PSR-4 agreement.

The only thing that has been changed is how the classes in /core/lib are loaded, but that is an internal, irrelevant detail of the classloader.

In addition, I agree with @webchick's assessment; the directory mostly contains individual components (~= libraries).

In short, changing the directory layout of /core/lib was never on the table.

It's not clear what you're suggesting. Do you suggest to do the following?

/core/lib/Drupal/Component/Utility  →  /core/src/Component/Utility
/core/lib/Drupal/Core/Utility       →  /core/src/Core/Utility

Notes:

Drupal core is an application framework that consists of many components itself (cf. Symfony, zf2, etc). A framework rather presents a set of libraries. As such, following the directory layout of the PSR-0 standard might make more sense (which has no impact on how the contained classes are loaded though).

The good news is that we do not have to document anything on our own, except of "This follows PSR-0." and "This follows PSR-4."

Counter-arguments/notes:

Guzzle 4 was recently included/upgraded in Drupal core, which also uses PSR-4 (for the better). That's an actual real world proof that PSR-4 is not only for "extensions of application frameworks"; it works under all possible circumstances.

Usage of the PSR-0 directory layout has no special effects on potential git-subtree splits of Drupal\Components in the future. Subtree splits would work with PSR-4, too.

Lastly, we didn't really achieve what we wanted to achieve with Drupal\Component for D8. Many contributors are questioning the sense of the separation from/to Drupal\Core already today. — I personally think it makes sense, but for the sake of full disclosure, without it, the above mentioned PSR-4 paths would shorten to:

/core/lib/Drupal/Component/Utility  →  /core/src/Utility
/core/lib/Drupal/Core/Utility       →  /core/src/Utility

(but again, I'd disagree with removing the Component/Core concept.)

A quick clarification: PSR-0 is no longer even relevant. PSR-4 is "directory to namespace mapping, with a configurable prefix". We just have the prefix configured differently for modules and for core. (A few people still are confused by that, so I'm restating it to be explicit.)

I don't feel strongly enough to burn karma on core/lib vs. core/src. If wishes were horses I'd do core/src, but I and not going to shed blood for it.

The /Drupal/ part of the directory never bothered me much. It made a bit more sense back when we had our included Symfony code in there, too, but we've long since switched to /vendor/ and are not going back. I don't expect us to be adding any more namespaces for our own code that aren't under /Drupal/. I have no particular desire to remove it, but I also won't be reduced to tears if we pull that out.

The Core and Component directories, though, I have no idea what the summary is talking about with "at the same level". If it's asking if that distinction is meaningful, the answer is 1000% yes. That split exists very deliberately to highlight and encourage the creation of Drupal-uncoupled components, something we should be doing more of. Removing those is not on the table. At all. If that's not what that line is talking about then I don't understand it in the slightest. :-)

I guess the "right way" to go about Core vs Component would be sth like

"psr-4":
  "Drupal\Core\\": "core/src/"
  "Drupal\Component\Foo\\": "core/vendor/Drupal/Component/Foo/src"

And move the top-level class \Drupal to class \Drupal\Core\Drupal.
It does not look like we are going to do this..

Besides that, I am with Crell, and prefer the solution of least drama. So far it seemed that not touching core/lib/Drupal is the most promising in this regard.

But if core/lib/ has one kind of directory-to-namespace mapping, and modules have another, and the reason is not "because the first one is PSR-0 and the second one is PSR-4"

I expect a number of projects will replace PSR-0 with "PSR-4 with full 1:1 namespace-to-directory.". This is a cheap way to get rid of the underscore handling, without moving any files around. It is perfectly legitimate, and mentioned in Jordi's blog post about PSR-4.

So, it could happen that in the future we will not discuss about PSR-4 vs PSR-0, but about PSR-4 with flat directories vs PSR-4 with deep directories.

Developing Drupal/Component outside of the core repo is not on the table (Dries has made that clear) so #9 (putting Drupal/Component in /vendor/) is not an option.

My "vote" would be to leave it as it is now, because of concerns explained at #3 and #4.

As far as I can see, everything has been said on this issue; status quo works as designed.

FWIW: re: #10:

Developing Drupal/Component outside of the core repo is not on the table (Dries has made that clear) so #9 (putting Drupal/Component in /vendor/) is not an option.

Dries made that decision ~2 years ago. Meanwhile we're able to identify clear and true benefits of doing it. Therefore, I predict it's going to happen for D9.

FWIW, adding a closely related issue.