Note that the PCS defines semantic, rather than visual, characters. That means, for example, that a character with the semantics of <backslash> must be supported, even if in some fonts, the backslash glyph has been replaced with a <Yen> sign, <c-cedilla>, or other glyph. A replacement glyph thus has two sets of semantics -- its own and that of the glyph it replaces. If a <Yen> appears in place of the <backslash>, it performs the functions of the Japanese currency symbol and of a <backslash>.
えっと (スコア:1)
コードの話と文字の話がごっちゃになってるような気がします。
OSF CHARACTER AND CODE SET REGISTRY INTRODUCTION [opengroup.org]に
とありますが，少なくとも 「Shift_JIS というエンコーディング」のみに限って話をした場合，「1バイトの英数字部分(i.e. \x20～\x7E)」が JIS X 0201 であろうが，ISO/IEC646 IRV であろうが，\x5C を yen-sign ではなく backslash として， \x7E を overline ではなく tilde として扱ってしまっても問題はないでしょう。
Shift_JIS で問題になるのは，まず backslash と yen-sign の違いなんかより，むしろ，2バイト文字の第2バイトに \x40～\x7E がくる場合があるということでしょう。第2バイトに \x5C や \x7C がくる文字を含んだ文字列を正しく処理できないといったことが起こりえますよね。
もうひとつの問題は，numa さんも指摘している文字との対応関係で，こちらは，他の(特に unicode 系の)エンコーディングと相互に変換する場合に問題が表面化することになると思います。ここは，確かに，非常に難しいところですね。
# 全然まとまってないや
Re:えっと (スコア:1)
コメントありがとうございます． お返事が遅れて済みません．
実は，Big5 など，外国の文字エンコーディングには2バイト目が 0x40～0x7E になるようなものが存在していて， Linux の glibc やコマンド類は，そういものにも対応できているのです． もちろん，ASCII しか考えていないようなプログラムも多いでしょうが，そういうプログラムには，euc-jp を使おうが utf-8 を使おうが通りません．
で，glibc の開発者の Ulrich Drepper とか， 分かっている人たちはそういうことも理解した上で， なお shift_jis は難しいと言っているのですよ．
まあ，本当のところ，何が問題で shift_jis を排除されているのかは本人に聞いてみないと分かりませんが，私はそんなにはずしていないと思っています．