>>3,5
That is really interesting stuff. I'm very surprised that you were using an immutable string class for C++ game development though because of the allocator stress and fragmentation it would cause (your link suspiciously mentions none of this.) Also if it's game development, why do you need to worry about encoding at all? Why not just use UTF-8 for everything (with a couple of helper functions to dump it into a native format where necessary)?
I've often wanted to write a string implementation like that, except with indirection built in so that the string data could be allocated from a special zone that compacts memory. Of course getting that right with multi-threading is extremely difficult/impossible. As far as I know there isn't a way to 'stop the world' in C++ the way a collector in a managed language can do. This means you're stuck using arbitrary memory barriers whenever you access strings in case their memory has been moved around by a different thread, which makes the whole thing so slow as to be useless.