It's broken.<p>Λ̊1 → ⊻∪ά → Λ̊⋌<p>𝄞 → 뤔뷾 → 駴點<p>Edit: anyway, even with correct (a+b)%n it's plain bad idea.<p>Unicode is not English alphabet. Everything not in basic multilingual plane is broken automatically. And even in BMP there's going to be bag of glitches starting from hanging combining characters and ending to ‘oops someone normalised our string and it's now different’ (for site, not for user / Unicode).
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
Inputting "こんにちは。元気ですか？" caused an application error:<p><pre><code> [ArgumentException: Error serializing value 'ᄳᅳᅋᅁᅏტ㈣䳷ᅇᄹᄫ�' of type 'System.String.']
</code></pre>
After realizing it was "？" that was breaking everything, I ended up with this round trip:<p>"こんにちは。元気ですか。" → "ᄳᅳᅋᅁᅏტ㈣䳷ᅇᄹᄫტ" → "こんにちは。ጃですか。"<p>It's broken. I suspect Unicode requires more careful manipulation than OP anticipated. :-)
Copy-pasting the contents of rot8000.com/info in and hitting cypher twice ends up scrambling the contents quite a bit..<p><pre><code> It also bypasses 32 control characters, technically making it rot7968, sometimes with an additional offset.
</code></pre>
-><p><pre><code> It also bypasses ⋍2 control characters, technically making it rot⋏⋬68, sometimes with an additional offset.</code></pre>
I put in a fix for CJK and the result is: nearly everything that's not CJK now rotates into it and back out; CJK is an <i>huge</i> section of the Basic Multilingual Plane. The fix invalidates rotations done with rot8000 before the fix, unfortunately.
I just realized that 13 was probably chosen for rot13 cause that's half the number of letters in English alphabet.<p>I miss "obvious" stuff like that all the time.