Let me just preface this with: inconclusive conventions are better than no standards at all. And there's probably 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 ⁴	✔	✘	✘	✘

¹ = Impractical, but symlinking dependency-conjoined class modules might be a feasible workaround.
² = Not just accidentally on some plattforms or filesystems.
³ = While prohibited, most PSR-0 autoloaders work with handicrafted phar:// paths in their namespace registry.
⁴ = Not a discreet PHP or Phar feature, and resolving dependencies is certainly still best left with composer, not done at runtime.

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 plattform ambiguity due to absent identifier-to-file case normalization issues from. Holding on to the handed down file structuring schemes is also why namespaces were interpreted as PHP 5.3s only significant addition, but Phar support disregarded.