str.decode() and bytes.encode() are not coming back.

Any proposal had better take into account the API design rule that the *type* of a method's return value should not depend on the *value* of one of the arguments.  (The Python 2 design failed this test, and that's why we changed it.)

It is however fine to let the return type depend on one of the argument *types*.  So e.g. bytes.transform(enc) -> bytes and str.transform(enc) -> str are fine.  And so are e.g. transform(bytes, enc) -> bytes and transform(str, enc) -> str.  But a transform() taking bytes that can return either str or bytes depending on the encoding name would be a problem.

Personally I don't think transformations are so important or ubiquitous so as to deserve being made new bytes/str methods.  I'd be happy with a convenience function, for example transform(input, codecname), that would have to be imported from somewhere (maybe the codecs module).

My guess is that in almost all cases where people are demanding to say e.g.

  x = y.transform('rot13')

the codec name is a fixed literal, and they are really after minimizing the number of imports.  Personally, disregarding the extra import line, I think

  x = rot13.transform(y)

looks better though.  Such custom APIs also give the API designer (of the transformation) more freedom to take additional optional parameters affecting the transformation, offer a set of variants, or a richer API.