There are a number of issues that need to be clarified before the proposed
extension will be ready for inclusion:
Do implementations have to support encodings of NUL ala ${hex:0}? If so,
that will be a barrier to this extension being broadly supported.
(I think it should be a "MAY support".)
Which comes first, encoding replacement or variable expansion? Or are
they concurrent? Whatever the answer, the variables I-D will need to make
that clear.
(I think encoding replacement should come before variable expansion.)
unicode-hex should be 1*6HEXDIG: the Unicode range goes up to 10FFFF
The next rev of the base-spec includes this:
Extensions MUST NOT change the behavior of the "require"
control command.
I believe that means that this extension can't be used in the capability
argument to 'require', so there's at least one place where Unicode
characters can't be encoded using ${unicode:...}.
I'll note that while a script that uses this extension for all non-UTF8
octets may be displayable without munging, the result may still be
incomprehensible if, for example, an 8bit ISO-2022-JP MIME part is
included in a string. Indeed, such encoding will probably make it more
difficult to display that MIME part readably: currently, if a user is
viewing the script with raw ISO-2022-JP in it they can probably display
that MIME part by overriding their browser's charset encoding for the
page.
Philip Guenther