▼ Uchiさん
> 1. システム外字として、IBMの外字ではなく、NECの外字を使用しなければならないファイル。
> 2. CP1252等のSJIS外のコードが入り混じったファイル。
> ｓjis部分だけの修正でしたのでそのままのコードが書き戻せればOKでした。
> 3. exeファイル。
> すでにソースが無い状態で、メッセージだけを書き換えなければならない状態で。
> 4. EBCDIC文字が混じったファイル。
> 汎用機とのインターフェース用のファイルでありました。

テキストを書けるバイナリエディタ「Thebe」を
お使い頂ければ、
恐らくその要件は満たされると思います・・・。
いかがでしょうか？

http://panathenaia.halfmoon.jp/thebe/

それに、どうもかなりの少数派の意見のようです。
その辺のことは・・・ちょっと微妙な状態です。

▼ Uchiさん
> > ちょっと個人的にアンケートさせて下さい。
> > SJIS のファイルを直接扱う必要性がある場面を、
> > 具体的に教えていただけますか・・・？ (^^;
> いろいろありますが、
> 1. システム外字として、IBMの外字ではなく、NECの外字を使用しなければならないファイル。
> 2. CP1252等のSJIS外のコードが入り混じったファイル。
> ｓjis部分だけの修正でしたのでそのままのコードが書き戻せればOKでした。
> 3. exeファイル。
> すでにソースが無い状態で、メッセージだけを書き換えなければならない状態で。
> 4. EBCDIC文字が混じったファイル。
> 汎用機とのインターフェース用のファイルでありました。

なるほど、そういった使い方もあるのですね。盲点でした。
貴重な情報をありがとうございます。
内部コードのwchar_t化の影響として、動作パフォーマンス以外に失うものは無い、
と自分は思いこんでいましたが、たしかにこれは重要なリスクです。

ただ、自分のビジョンを述べさせていただきますと、
wchar_t管理にしてしまうことによる、開発サイドへの悪影響が生じるのであれば、
今すぐにでも作業方針を見直そうと考えていましたが、
逆に、(快適なANSI版を望む)ユーザの方々には、申し訳ありませんが、
開発サイドが安定するまで、少しの間お待ちいただきたいと考えている次第です。

UNICODE化したばかりの、サクラエディタでは、
それに付随するANSI版には、Uchiさんがおっしゃるような不具合(恐縮ですが、その時点での仕様とも言えます)が生じるはずです。
当然、そのような動作の差が生まれたとしたら、互換性を考え、現行のANSI版サクラエディタも公開したままにしておき、
ユーザがどちらを使うか選べる状態にしておきます (、、よね？＞げんたさん、ラスティブさん)。

実装上の話になってしまい恐縮ですが、
>>dev:5037に書きました通り、内部wchar_t化した後の、再度のchar対応は
可能ではあります。
要望があるのであれば、先のことになってしまうと思いますが、
その作業を行い、新しいバージョンのサクラエディタでも
Uchiさんのおっしゃるような機能(つまり、現行のANSI版と互換性のある機能)を
提供できると思います。

ただ、数の暴力ととられるかもしれませんが、
時代を考えると、UNICODE版を主ターゲットとした開発がメインとなり、
ANSI版への細かい要望がなかなか反映されない、という状況が予感されるのも事実です。

そのときは、現在、Uchiさんが
現行のサクラエディタをメイン(？)に使い、モカさんのUNICODE版を2ndエディタとして使っていますように、
UNICODE版開発が主流になってしまった(場合の)未来には、
そのときから見れば古い(2007年現在の)ANSI版サクラエディタをメインに使っていただき、
新しいUNICODE版サクラエディタを2ndエディタとして使っていただくという選択肢を
提案させていただきたいと思うのですが、どうでしょうか。

と、書いてる間に
ラスティブさんからも「Thebe」というソフトがご紹介されていますね。
残念ですが、そういった別ソフトを使っていただく、
というのも選択肢としてお考えいただきたいです。

否定的な返答になってしまい、申し訳なく思っています。
ただ、Uchiさんがおっしゃるようなリスクがあることは念頭に置いておきます。
貴重なご意見ありがとうございました。