マルチバイト文字の扱いの改善を訴える……何処へ？

Ada

HaskellにCPUパワー100%で長時間計算させるタイプの処理をさせようとした私が間違っていました。とにかく遅い。じゃあHaskellって実際問題何に使えるんだよって疑問も沸々としてるのですがそれは置いときます。ついでに評価関数もなんか間違ってたような気がしたところで、Adaに書き直すことにしました。
さてAda2005では最近の言語よろしくUnicode識別子が認められています。

type Kana is (あ, い, う, え, お, ...);

他の言語ならこれは余り嬉しくないのですが、Adaには'Imageと'Valueがあります。
caseをだらだら書かなくても、読み込んだテキストをKanaによる表現に変換するには、単に一文字ずつKana'Wide_Value(C)で済みます……済む筈です……本当なら。
いつもいつもマルチバイト文字の不遇な扱いには辟易していたのですが、さすがに我慢の限界に……。
そもそもGNATは-gnatWsとか-gnatWeでShift-JISやEUC-JPが扱えるつもりになっているフロントエンドですが、どう考えても仕様ミスがあるため、事実上は全く使えません。Wide_Stringに生のJISコードが格納されても全く嬉しくないですし、素直にStringにMBCS表現で値を埋めて欲しい箇所で尽く律義に範囲チェックしてはじきやがるのはもう意味不明です。
で……何処へ？
gccメーリングリストはちょっと違う気もしますし、AdaCoreは有償サポートを受けているならともかくタダで使わせてもらってる分際でバグレポート先にするのはやっぱ違いますし、GNAT GPLのサイトにはbug reportなんてコーナーは無いですし。まあ、gcc-patchesにパッチ投下が一番なのはわかってますが、GNUとAdaCoreとの二重管理がどーなってるのかいまいちわからんのですよね。果たしてAdaCore以外でパッチを投下してる人がいるのか……いや、いない。し、やったら逆に邪魔になりそうです。
というわけで人の目につけば何とかなるだろう戦術を取ることにしてcomp.lang.adaに色々投下してみました。
orzその1。いつも以上に英語がやばいです。意図が伝わる気が全くしません。どなたかヘルプです。
orzその2。これを書いている最中にNiftyからこんなメールを受信しました。

　【インターネットニュースサービスの終了について】

　　　サービス終了日：2006年9月30日

　　　対象サービス：　インターネットニュースサービス

　　　対象サーバ名：　...

追記
奇妙なカタコト英語の闖入者に対し、comp.lang.adaの常連さん方は親切です。
「そのパッケージつかったことは無いけどバギーでも驚かないね。経験上、AdaCoreは文字エンコーディング関係の扱いについてかなり風采があがらない」という実に頼もしい言葉をいただいた上で、妥当な報告先はhttp://gcc.gnu.org/bugs.htmlだと教えていただきました。