Let me just preface this with: inconclusive conventions are better than no standards at all. And there's really nothing <i>news</i>worthy here.<br>
Due to the ellipses in the PSR-x documents it's however helpful to detail some technical deviations and oversights.

<style>
  .yes  { background: #bbeebb; }
  .no   { background: #eeccbb; }
  .part { background: #eedd99; }
  td, th { text-align: center; }
  td:first-child { text-align: left; font-weight: normal; }
  ol { }
</style>

<table width=100%>
<tr>
  <td style="text-align:left"><b>Feature</b>
  <th>PHP
  <th>PSR-0
  <th>PSR-4
  <th>shared
<tr>
  <td class=yes>Class autoloading
  <td class=yes>✔
  <td class=yes>✔
  <td class=yes>✔
  <td class=yes>✔
<tr>
  <td>Zero configuration
  <td class=yes>✔
  <td class=yes> ✔
  <td class=no>✘
  <td class=no>✘
<tr>
  <td>Multiple class declarations per script
  <td class=yes>✔
  <td class=no>✘ ¹
  <td class=no>✘ ¹
  <td class=yes>✔
<tr>
  <td>Namespace support
  <td class=yes title="optional">✔
  <td class=yes title="predicate">✔
  <td class=yes title="prediacte">✔
  <td class=yes title="optional">✔
<tr>
  <td>Multiple namespaces per file
  <td class=yes>✔
  <td class=no>✘
  <td class=no>✘
  <td class=yes>✔
<tr>
  <td>Syntax verification
  <td class=yes>✔
  <td class=no>✘
  <td class=no>✘
  <td class=part title="Only partially with the tokenizer update.">✘
<tr>
  <td>Specific underscore treatment
  <td class=yes>✘
  <td class=yes> ✔
  <td class=yes>✘
  <td class=yes>✘
<tr>
  <td class=yes title="Cross-plattform unambiguousness">Case-insensitive class identifiers ²
  <td class=yes>✔
  <td class=no>✘
  <td class=no>✘ ²
  <td class=yes>✔
<tr>
  <td>Function names
  <td class=yes>✔
  <td class=no>ⁿ/ₐ
  <td class=no>ⁿ/ₐ
  <td class=yes>✔
<tr>
  <td>Case-variant constants
  <td class=yes>✔
  <td class=no>ⁿ/ₐ
  <td class=no> ⁿ/ₐ
  <td class=part>✘
<tr>
  <td class=yes>Phar package support
  <td class=yes>✔
  <td class=no>✘ ³
  <td class=part>✘  ³
  <td class=yes>✔
<tr>
  <td>Versioned bundles ⁴
  <td class=part>✔
  <td class=no>✘
  <td class=no>✘
  <td class=no>✘
<tr>
</table>

<ol>
 <li> Impractical, but symlinking dependency-conjoined class modules might be a feasible workaround.
 <li> Not just accidentally on some plattforms or filesystems.
 <li> While prohibited, some PSR-0 and a few PSR-4 autoloaders work with handicrafted paths in their namespace registry.
 <li> Dependency resolution is mostly off-scope for runtime autoloading, and obviously best left with composer.
</ol>

#### 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 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](wiki/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.