あくまで私見ですが、アプリケーションプログラムを作成する際に最初に決めなければならないのは、漢字コードに何を使うか、です。
漢字を含む文字列リテラルをどう記述するかをはじめ、文字列処理のためのロジックをどうするかも、文字コードに何を使うかによって変わってきます。それらがソースコード全般にばらまかれることになるので、これを後から変更するのはとても面倒です。
今どきshift-jisのような古くて出来の悪い文字コード体系向けのロジックを書きたいとは思わないですが、かといってMicrosoft流にすべての文字処理にwchar_tを使うというのも、スタンダードから随分と離れたプログラミングが必要になってしまいます。両対応にすべく文字列リテラルを書く度に_T(“HOGEHOGE”)とかのマクロをばらまくのも如何なものかと思います。
幸い、WideStudio/MWTではutf-8でソースを書けます。文字列リテラルも（少なくとも画面周りについては）utf-8のままでMWTのライブラリに渡せばその先で変換して処理してくれます。
utf-8は漢字を表現するのに3byte以上を必要とするのがデメリットと言えばデメリットですが、今どきその程度の記憶領域などさしてもったいなくもありません。何より、漢字を表すコードの各バイトは絶対にascii文字列と重なりませんし、文字の先頭のバイトなのか2バイト目以降なのかの判定も簡単です。タンゴレンは最初からunicode対応にする予定でしたからあまり迷わずソースコードを記述するための文字コードはutf-8をベースに開発することにしました。
内部の文字列処理（検索処理とか）については当初何も考えなくても一文字単位で処理出来るutf-32を使う予定でしたが、開発途中でICU (International Components for Unicode) ライブラリの存在を知り、これを使うことにしたためutf-16leベースになりました（ICUはutf-16ベースです）。
単語帳ファイルへの単語データの格納はutf-16leで行なわれています（…これは当初の予定通り。お陰でコード変換（utf-32→utf-16）が必要なステージが１つ減りました）。utf間のコード変換は簡単ですし文字が化けることもないので気楽です。