> Thunderbirdは確かにまだバグだらけみたいです。
> リリース版でも、デバッグビルドすると、起動して画面が出るまでASSERTを何度も吐きながら動きます。
> 怖くてしょうがないです。
ASSERT吐き出してますか。私はopen sourceのもので自分でビルドしてまともに動いたことがないので一切自分でビルドするのはやめました。
Thunderbirdに関しては ただのユーザーであると同時に「使うためにはバグをどう回避するか」という点だけに注意しています。

> メールの移動はやたらと時間がかかるところ、不安になって強制終了すると大体データがどこかに消えます。
これ、知らずに一回やりましたが、その時は消えませんでした。
ソースがunixと共通だとしたら、Windows特有のお約束である「ファイルアクセスのエラーリトライ」を上手くやっていないのかも知れないっていう気がします。
業務プログラムではopenからclose・次のプロセスでのopenまで、Windowsのバッファ書き込みとclose処理が間に合わないことが多いので、必ずアプリでリトライを行わないと、プロセス間でのファイル受け渡しによく失敗します。（500msec以下の処理が出来ないっていうやつとか、CPUオーバーロード気味のときの処理取りこぼしなど。CPUの処理が速いほど顕著）
またThunderbirdに関しては観察している限りファイルの排他制御がぜんぜん上手くなような気がします。（表示されるダイアログは排他制御の順番待ちではなく、単にファイルアクセスエラーのタイミングで出ているような気がします）
ファイル破壊に関しては おそらく、Linux版などunix系では起こらない不具合だと思います。


> 色々やってきた所では、「日本語と英語のメールを別々に扱う」というのが一番効果が高い方策のようです。
> 次に、subjectのMIMEデコード。
> が、これを正規版に組み込むことを納得させるだけの実績と実装がいるので躊躇しているところです。
日本語と英語を別々に扱う件はオプションスイッチでユーザーが選択できるように、また日本語と限定せずに「マルチバイト文字とASCIIなどを別々に扱うオプション」として実装を主張できれば良いかも知れません。
SubjectをMIMEデコード後に走査する件は、「ジャンクを作成したタイミングのソースはエンコード前の状態であるからデコードしてから走査するのが自然である」ということを主張するしかないのでしょうか。これも、オプションスイッチで「MIMEデコード後にヘッダ内を走査」とか選択肢をユーザーに認識させて、速度低下に対する認識の保険が必要なように思います。

＃ でも現行の方式でヘッダ込みで無理やりジャンクに特定できるのも捨てがたいです。（意図した機能でないとしても）
これは相手のメールアドレスを「アドレス帳に登録済みはジャンクとしない」という機能と同様にEudoraのベイジアン・フィルタと同じように「登録アドレスはジャンクとして扱う」という機能が有れば便利です。
また、メッセージフィルタの方と自然に連携できる仕組みも必要だと思います。（今は一発で出来ない）


> 漢字かな混じりの単語でトークン登録するのは、微妙なところです。とにかくEffect is everythingです。処理を複雑にするのは速度面でよくないでしょうし、またそれで効果がどれだけ上がるかということについて、不明です。
これは、ジャンクフィルタ機能にもextensionが利用出来るような仕組みを作っておいて、後で追加するという方法をとればThundebirdの本体（再ビルドやビルド対象ソースのことなど）を気にせずに開発できるようになるかも知れませんね。（つまりトークンの解析機能を外出ししておけば今まで通りの機能でよいか、漢字仮名混じりのトークンが必要かをユーザーが選択できる、とか）