> transform() and untransform() methods were also removed, I don't remember why/how exactly,
I don’t remember either; maybe it was too late in the release process, or we lacked enough consensus.

> So we have rot13 & friends in Python 3.2 and 3.3, but they cannot be used with the regular
> str.encode('rot13'), you have to write (for example): codecs.getdecoder('rot_13')
Ah, great, I thought they were not available at all!

> The major issue with {bytes,str}.(un)transform() is that we have only one registry for all
> codecs, and the registry was changed in Python 3 [...] To implement str.transform(), we need
> another register. Marc-Andre suggested (msg96374) to add tags to codecs
I’m confused: does the tags idea replace the idea of adding another registry?

> I'm still opposed to str->str (rot13) and bytes->bytes (hex, gzip, ...) operations using the
> codecs API. Developers have to use the right module.
Well, here I disagree with you and agree with MAL: str.encode and bytes.decode are strict, but the codec API in general is not restricted to str→bytes and bytes→str directions.  Using the zlib or base64 modules vs. the codecs is a matter of style; sometimes you think it looks hacky, sometimes you think it’s very handy.  And rot13 only exists as a codec!