Let me just preface this with: inconclusive conventions are better than no standards at all. And there's really nothing newsworthy here.
Due to the ellipses in the PSR-x documents it's however helpful to detail some technical deviations and oversights.
|Multiple class declarations per script||✔||✘ ¹||✘ ¹||✔|
|Multiple namespaces per file||✔||✘||✘||✔|
|Specific underscore treatment||✘||✔||✘||✘|
|Case-insensitive class identifiers ²||✔||✘||✘ ²||✔|
|Phar package support||✔||✘ ³||✘ ³||✔|
|Versioned bundles ⁴||✔||✘||✘||✘|
- Impractical, but symlinking dependency-conjoined class modules might be a feasible workaround.
- Not just accidentally on some plattforms or filesystems.
- While prohibited, some PSR-0 and a few PSR-4 autoloaders work with handicrafted phar:// paths in their namespace registry.
- Dependency resolution is mostly off-scope for runtime autoloading, and obviously best left with composer.
Origin of PSR-0/4
PSR-4 inherits the PSR-0 design as intended for and from PHP framework maintainers. Retaining the traditional class directory structures was the protogenic goal then. PSR-4 constitutively just removed the PEAR-style name splitting.
Which is where the absent identifier-to-file case normalization issues from. The focus on legacy directory schemes is also how Phar support got completely disregarded (as if PHP 5.3 was only about namespacing all the things).
Composer is married to PSR-0/4. Technically it's not a dependency, as highlighted by Composers very own classmap generator. (Which however stockholm-syndromes the shallow singly-namespaced-class-per-file semantics, invalid identifier mapping, and overlooked phar support).
As package installation mediator it can however abstract away some source management deficiencies. Applying some late common sense and
strtolower becomes a facile possibility.