ここまで問題がこじれてしまったら、もう内部コードは誰かが
適当文字コードをでっちあげて、wchar的なライブラリを作って、
それを使う形にするのが早道だと思う。ISO C localeとだいたい
同じ発想だけど、実装が1つなら変な非互換問題は出ないし、
complex-textに対応する余地も広がる。
外部コードは、どうせコード変換すれば済むから、正直何でもいい。
その時は、

1.M17Nは諦める。本格的なM17Nが必要な場面では、普通は文字より
グリフが必要とされるから、TRONでも使っておく。

2.ファイルシステムで多言語を使いたい、というような要求は、
M17Nというより、「世界共通ロケール」というべきものだから、
全部UNICODEで表して、世界共通のcollation(単なる数字の比較
でも十分だろう)とかも決めてしまうのが正しい。

3.I18Nに限定すれば、バックスラッシュ問題なんかは全部locale
ごとにポリシーを決めれば済むから、互換性問題はクリアできる。
合字や包接の扱いも、localeのポリシーで決める。ここはSJIS等で
昔から行われて来た習慣に素直に従う。

4.外部コードと内部コードを厳密に区別する。たとえ内部コードに
UNICODEもどきを使うとしても、それはSJISなりEUC-JPなりの
内部表現であって、UNICODEとは別物であるとはっきり決める。
当然ここでは、そのlocaleで1対1に変換できることを優先する。
逆に、外部コードとしてのSJISとUNICODEが1対1でなくても、それは
変換したユーザの責任とする。

ここまでやれば、最大限互換性、柔軟性を確保できると思う。
相変わらずWebページの文字コードをどうするか、とかそういう問題が
残るにしても、内部コードじゃないから、1対1の縛りは弱い。だから、
「ページを作る人が勝手に決める」でも何とかなる(現にあまり問題に
なっていない)。逃げと言われればその通りではある。