結局、仕様はこうなりました。
texmf.cnf で、 command_line_encoding なる変数を用意する。
command_line_encoding で、"utf-8" または "utf8" を指定されていると、該当プログラムは、コマンドラインの文字列をUnicodeで解釈し、UTF-8の文字列として内部に取り込む。ファイルのopenなどは、Unicodeで行う。
command_line_encoding で、"" を指定、またはcommand_line_encodingの指定が全く無いと、該当プログラムは、コマンドラインの文字列を従来の文字コード(日本語WinodowsではCP932(Shift_JIS))で解釈し、従来の文字コードの文字列で内部に取り込む。
up(la)tex, dvipdfmx,dvips では、command_line_encoding=utf-8 と指定しておけば
uplatex 尾骶骨.texなどがうまく動く。
dvipdfmx 尾骶骨.dvi
kpsewhich -progname=uplatex 尾骶骨.tex
uplatex ♥.tex
dvips ♥.dvi
kpsewhich -progname=uplatex ♥.tex
command_line_encoding.dvipdfmx=utf-8
などの書き方でプログラムごとにコマンドラインの文字コードの切り替えが出来る。
この動作に対応したプログラムは、(e)uptex, xetex, dvips, dvipdfmx, xdvipdfmx, kpsewhichなど。
( 残念ながら luatex では、luaコードにトラブルが出るとのことで不採用でした )
ls-Rの中の文字コードは何も配慮していないので、マクロやフォントのファイル名はASCIIの範囲にとどめておかないと、kpathsearchで見つけることが出来なくなる。
従来の動作も可能にしたまま、うまく拡張することが出来たと思っています。
Windows 95,98,Me系は全く考慮していませんが、XPですらサポート切れの時代なのでもういいでしょう。
以下は、開発に興味がある人へのご参考です。
改造は、大体以下のとおりでした。
コマンドライン、コンソールの読み書きに ReadConsoleW(), WriteConsoleW(), GetCommandLineW(), CommandLineToArgvW() などを使用する。
fopen(), popen(), spawnvp()の代わりに_wfopen(), _wpopen(), _wspawnvp()などを使用する。
command_line_encoding の設定状況に応じて、文字コードを読み替えつつ動作させるラッパー関数をkpathsearchライブラリに用意する。
アプリケーション側で使用する関数をラッパー関数に置き換える。
私はTeXLiveをWindows 7上、MinGW32でコンパイルしてテストしました。普通はlibtoolを使ったlinkが行われるようですが、その場合コマンドライン上のUnicodeが上手く渡されませんでした。ライブラリを直にlinkさせると上手く動きました。
このあたりは、私はよく分かっていません。
もう少し凝ると、「英語(非日本語)版Windows上でp(la)texを使う場合にCP932の範囲の漢字ファイル名を使う」「日本語版Windows上でp(la)texを使う場合に、内部コードをEUCにしつつ漢字ファイル名を使う」みたいなことも出来そうなのですが、需要も少ないでしょうし、ソースコードが若干複雑化するので自重しています。