The change in 2.7.9 upstream was *absolutely* the right thing for the upstream CPython community to do. The problem was real, it needed to be fixed, and the community fixed it in a way that works just fine for folks in the earlier parts of the technology adoption curve.

Change management for the folks in the latter half of the technology adoption curve is a key part of what commercial redistributors get paid for. Delaying PEP 476 while we figured out the details of how that was going to work would have been a bad plan from a community perspective, so I took a speculative shot at providing a very simple solution for the redistributor case and unfortunately missed the target.

The reason I still want to negotiate the technical details of the feature upstream (despite missing the mark in PEP 476 itself) is so that all of us that need this functionality can provide the *same* behaviour to our respective customers, rather than having Red Hat do one thing, Suse another, Canonical a third, and then cross-platform Python redistributors like eGenix and ActiveState also needing to figure out their own scheme. It's akin to the problem faced by Linux redistributors that independently provide stable ABI guarantees, but also aim to collaborate on backporting fixes to the *same* stable ABI to reduce duplicated effort: http://crunchtools.com/deep-dive-rebase-vs-backport/#Brief_History

So while this isn't a feature upstream itself needs, it's one potentially needed by multiple *downstreams*, so in my view it makes sense for us to work with upstream to come up with the "one obvious way" for redistributors to handle the problem (now that we know that my initial attempt at providing such a way doesn't work in practice).

Probably the closest precedents to this idea are PEP 394 (regarding management of the unqualified python symlink) and the section with recommendations for downstream redistributors in PEP 453 (bundling pip).