One could argue that a filesystem which contains two files, one in ASCII and one in EBCDIC, is on the whole just single mapping of characters to numbers. Your point isn't well argued.

What I'm suggesting differs in that it would use consistent tags to indicate deviations from the intended primary language of a string.

Surround sections of a string which should be interpreted differently with tags-bits indicating such. These tags should not be treated as characters as the mirror character described in the article obviously is. And finally, display routines would easily be able to indicate what's what; any sections of the string with tags indicating an alternate encoding could be displayed with bold, highlight, or in a different color. (ie. As in "ti<cryllic>a</cryllic>n<cryllic>a</cryllic>nmen square", except the tags would simply be unused bit-patterns.)

To accomplish the same thing with a Unicode string, one would have to store a list of ranges of code-points which correspond to the string's locale. Then, anything which isn't in one of those ranges could be displayed in the alternate color. (ie. A character outside of the range 32-126 would be considered "not EN-US". For other languages, the code-point ranges might be more complex.)

The scheme I suggested isn't great, but it would avoids having to compare each character to see if it falls somewhere in a list of ranges for the current locale.