This issue has not been lost. It is the primary reason my proposal advocates
the use of a single character set.
Both Real- and what I'll call the "identify charset" approach suffer from
this problem. Real- can identify a charset on a per-header basis, but it
cannot specify more than one character set for a single header. Since most of
the applications I can think of for multiple character sets occur within
the same header, neither proposal seems very effective in this way.
The approach of simply identifying the character set used in a given header,
as opposed to duplicating the header entirely, can easily be extended to
deal with multiple character sets in different headers. Thus, for all
intents and purposes this issue is a non-issue when selecting between these
approaches.
The only approach proposed thus far that does address the multiple charsets
in a single header problem was the one RFC-XXXX had in it months back, where
tags were used in various places and the real text appeared elsewhere. This
is the only approach I know of that deals with the multiple character set
problem in full generality. It was also shot down in flames some time back.
As a result of the fact that this approach, which is the only one that
deals with multiple character sets cleanly, was aborted, I at least have gone
on to propose a model where the issue can be avoided. Specifically, use
mnemonic as a sort of "super" character set. Mnemonic can be thought of as
an encoding of 10646 if you like. As long as it remains aligned with 10646
(and I think Keld plans on doing just that) mnemonic is just an encoding
that happens to be readable rather than gibberish.
I still like mnemonic, and this only enforces my liking of it.
Ned