That's unfortunate; it would clearly have been easier to change this in 3.1.

That said, I'm not sure anyone *should* be subclassing PyUnicode.  Maybe
Marc-Andre can explain why he is doing this (or point to the message in
this thread where he explained this before)?  If it's a viable use case,
it should be possible to have some symbol or a few symbols whose
presence can be tested in the preprocessor by code that needs to
subclass; we should design the patch with that in mind and Marc-Andre
could help testing it.

All this is assuming the speed-up is important enough to bother.  Has
anyone run a comparison benchmark using the Unladen Swallow benchmarks?
 I trust those much more than micro-benchmarks (including, I assume,
stringbench.py).  I do expect that reducing the number of allocations
for short-to-medium-size strings from 2 to 1 would be a significant
speed-up, but I can't guess how much.