This a good writeup, thanks for doing it. A few points to add:

PSR-1 and PSR-2 started off as the same thing, but they became split to allow projects willing to take part in everything PSR-1 has to offer, without having to switch their tabs to spaces, or put their brackets on certain lines, etc. This is very important, as it allows the crucial parts (make sure its UTF-8, dont use ?> and get junk white-space, etc) to be implemented.

Another benefit is PSR-1 is allows everything on the outside to look identical. I can USE any package from anyone following PSR-1 and from inside my application (but outside their component) it is all consistent (camelCase). But inside their component, I probably don’t care what they do. This works nicely for PyroCMS, which is itself transitioning to PSR-1 and uses PSR-1 components. If component developers want to adopt PSR-1 and not PSR-2 then WHOOP whatever, but I still get all the functional compatibility & non-destructive benefits. :)

As for the numerical numbering, do not apply too much meaning to them. They are just incrementing IDs and have no other meaning, it just so happens the first few happened to be related. PSR-4 could be a Cache interface and PSR-5 may well be a new and improved autoloader.

I’m putting together a workflow for the FIG which is very similar to PEP (for Python) where their PEPs may be accepted or rejected but still have a number, so in the above example PSR-4 and PSR-6 might exist, but PSR-5 could well be rejected for a while (or forever) then get revived later down the road. It’s just a name, they’re not related!

But on the whole, this is great.