Not reciprocal for CJK input, e.g. "한글" takes 5 iterations to reach stability. I believe this has to do with the utf-16 encoding of codepoints > 0x10000
I was considering the fact that when it adds 0x8000 or whatever it's doing it's hitting 0x1.... codepoints and doing weird things with those because of the encoding. Here's a trace of 한글 through this 'rot8000', though:
So... yeah. Weirdness all around. Might have better luck doing this with some carefully crafted xor pad for each codepoint so that it's likely to hit a printable character but impossible to hit a character in the 0xD800..0xDFFF range (and similar ranges)... trying to "wrap" in unicode would require reinterpreting the codepoints to some continuous numeric representation.