I don't think that changing the possible return of PyUnicode_AS_UNICODE is reasonable. (option 1)

Option 2 breaks the buffer interface.

Option 3 severely limits the size of potential unicode strings.  If you are only manipulating tiny unicode strings (8k?), then the effect of fast concatenation, slicing, etc., isn't terribly significant.

Option 4 is possible, but I know I would feel bad if all of this work went to waste.


Note what M. A. Lemburg mentioned.  The functionality is useful, it's the polymorphic representation that is the issue.  Rather than attempting to change the unicode representation, what about a wrapper type?  Keep the base unicode representation simple (both Guido and M. A. have talked about this).  Guido has also stated that he wouldn't be against views (slicing and/or concatenation) if they could be shown to have real use-cases.  The use-cases you have offered here are still applicable, and because it wouldn't necessitate a (not insignificant) change in semantics and 3rd party code, would make it acceptable.