Victor, the general purpose codec infrastructure is more than a decade
old, and supported in both Python 2 and Python 3, so you're not going
to get it deprecated in the last few days before the 3.4 feature
freeze. You've already succeeded in inconveniencing affected users
migrating from Python 2 for another release by blocking the
restoration of the transform codec aliases, but I'm definitely not
going to revert any of the other already implemented codec handling
improvements without a direct request from Larry as release manager or
Guido as BDFL.

If you propose a new codec architecture as a PEP for Python 3.5 and
get it accepted, then *that* would be the appropriate time to remove
these improvements to the existing architecture. Until such a PEP is
put forward and accepted, I will continue to work on documenting the
status quo as clearly as I can (especially since the only thing I see
wrong with it is the challenges it poses for type inference, and
that's a pretty minor gripe in a language as resistant to static
analysis as Python).

I've tried to persuade you that lowering the barriers to adoption for
Python 3 is a more significant concern than a mythical nirvana of
conceptual purity that *runs directly counter to the stated intent of
the creator of the current codec architecture*, but if you wish to
exercise your core developer veto and deliberately inconvenience
users, even though the original problems cited in issue 7475 have all
been addressed, that's your choice. Just don't expect me to try to
defend that decision to any users that complain, because I think it's
completely the wrong thing to do.