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.

Feature	PHP	PSR-0	PSR-4	shared
Class autoloading	✔	✔	✔	✔
Zero configuration	✘	✔	✘	✘
Multiple class declarations per script	✔	✘ ¹	✘ ¹	✔
Namespace support	✔	✔	✔	✔
Multiple namespaces per file	✔	✘	✘	✔
Syntax verification	✔	✘	✘	✘
Specific underscore treatment	✘	✔	✘	✘
Case-insensitive class identifiers ²	✔	✘	✘ ²	✔
Function names	✔	ⁿ/ₐ	ⁿ/ₐ	✔
Case-variant constants	✔	ⁿ/ₐ	ⁿ/ₐ	✘
Phar package support	✔	✘ ³	✘  ³	✔
Versioned bundles ⁴	✔	✘	✘	✘

1. Impractical, but symlinking dependency-conjoined class modules might be a feasible workaround.
2. Not just accidentally on some plattforms or filesystems.
3. While prohibited, some PSR-0 and a few PSR-4 autoloaders work with handicrafted phar:// paths in their namespace registry.
4. 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 relationship

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.