Gather feedback about DX of Drupal\user\SomeClass existing in deep directory core/modules/user/lib/Drupal/user/SomeClass.php

In #1290658-136: Move all module-provided classes to PHP namespaces (PSR-0 or similar), and autoload them without the registry [policy, no patch], a decision was sort of reached to start using $moduledir/lib as the PSR-0 root for classes about to be made from core modules. As one example, consider the newly announced Layout initiative. From EclipseGc's blog post:

Create a standard interface and class specification (plugin) that works to satisfy existing needs of blocks...Migrate existing blocks to the new structure.

What this means is we will soon see core patches for moving existing core blocks into classes. As an example, let's assume the user module's Who's Online block becomes a class Drupal\user\Block\Online (note, it might be named something else, this is just a currrent guess). The current plan is for this class to live in core/modules/user/lib/Drupal/user/Block/Online.php.

As pointed out in #1290658-131: Move all module-provided classes to PHP namespaces (PSR-0 or similar), and autoload them without the registry [policy, no patch], we're not just talking about blocks, but other things too that make sense to move to plugins.

In #1290658: Move all module-provided classes to PHP namespaces (PSR-0 or similar), and autoload them without the registry [policy, no patch], several people raised concerns about the DX of such deep directories. See, for example, comments by Damien, sun, and donquixote.

Note that for contrib, several possibilities exist to make the structure shallower, from using the .info file to remove the need for a lib directory, to using PHP's spl_autoload_register() function to add a contrib autoloader that isn't restricted to PSR-0. We may well see such an autoloader appear as a contrib module that other contrib modules can add as a dependency in order to use shallower directories for their classes. Doing so would add a bit more work to non-Drupal projects that want to re-use the classes provided by a Drupal contrib module, but some contrib module authors may choose to prioritize their own DX ahead of the DX of those projects.

So, let's focus this issue on core modules, not contrib. What we need to uncover in this issue is what is the DX impact of having deep directories within core modules as outlined above. If the DX impact is sufficiently negative, some options include:
- Change core/modules to core/DrupalModule and use DrupalModule rather than Drupal to namespace Drupal modules. Thereby, the class DrupalModule\user\SomeClass can be in the file core/DrupalModule/user/SomeClass.php.
- Add a non-PSR-0 autoloader to core in addition to the PSR-0 one, and not follow PSR-0 standards for core modules.
- Possibly others.

Each of the above options have their own trade-offs. Let's not focus on the merits of those options at this time, but instead simply try to clarify the question of What are the concrete pain points of the currently proposed plan (deep directories)?

Assigning this major priority, because prior conversations on this topic have been heated, and this is something that affects every core module contributor, so gathering feedback from many stakeholders is needed.