各パートにはContent-Typeが付いているんだから、それを見ないで順番決めうちで表示するなんてバグでしょう。

なるほど、わかりやすい解説ありがとうございました。
プレーンテキスト→HTML という順序が基本というルールがメールの
世界にあって、それを逆にしたメールを送信するほうが悪いということ
ですね。確かに一理あります。そういう困ったメールでも
正しく表示できるようソフト側で融通を利かせてもいいようにも
思いますが、バグというわけではないのですね。

ちなみに順序を逆にして送ってくるメールというのは、
楽天トラベルの予約確認メールです。気づいて対応してくれると
いいですが、、、

ありがとうございました。

RFC の深いところまで知っているわけではないのですが、さしあたって記憶に残っている範囲で......。

プレーンテキスト形式と HTML 形式の両方を持つメールでは、Content-Type が multipart/alternative になっていると思います。

マルチパートなメールのうち、Content-Type が multipart/alternative で定義されるものは、各パートは同一内容で、表示条件に応じて代替的に表示するようになっています。各パートは、まずプレーンテキスト、ついで HTML というように、よりシンプルなものからより複雑な内容のものになるよう、並び順に一定のルールがあったはずです。

Thunderbird から、[テキストと HTML] の形式で送信した場合、マルチパートの順序が必ず プレーンテキスト -> HTML の順になるのは、この規格に則っているからだと思われます。

受信したメールを表示する場合は、Thunderbird は上記の順序に従い、[メッセージの表示形式] をプレーンテキストにしたときは前半のテキストパートを、HTML（オリジナル HTML またはシンプル HTML）にしたときは後半の HTML パートを、それぞれ狙い打って表示を切り替えているようです。
このため、ご質問のような現象が起こっているのではないでしょうか。

HTML 形式の表示に対応している他のメールクライアントでは、含まれるマルチパートの順序に関係なく、ユーザーが選択した表示形式で解釈できるパートを自動選択して表示するものがあるかもしれません。
このほうが柔軟性は高いですが、あらゆる受信環境での再現性を考慮すると、各パートの並び順に一定の意味を持たせておくことは重要で、それに基づく解釈で動作することは必ずしも悪いこととはいえません。

そのような観点でいえば、Thunderbird の動作は、"融通が効かない" とはいえますが、必ずしも "間違った動作" とはいえないように思えます。（調べてはいませんが、もしかしたらこのあたりのバグがたてられているかもしれませんね。）

個人的には、プレーンテキスト + HTML 両対応のメールのマルチパートの順序を、HTML -> プレーンテキストにしてくる送信側のほうに、より大きな問題があるんじゃないかと感じます。

記憶に頼った話で申し訳ありませんが、とりあえず以上です。間違ったことを書いてたらすみません。

Mac OSX 10.6 で、Thunderbird 8.0 を使用しています。

html 形式と、プレーンテキスト形式を両方つけているメールで、
html とテキストの切り替えがうまくいきません。
「表示」→「メッセージの表示形式」で html を指定しても、プレーンテキストしか
表示されません。

同じようにプレーンテキスト形式を両方つけているメールでも、
HTML になったりならなかったりします。
ソースを調べてみると、どうやら、プレーンテキスト部分が先で、
その下に html パートが来ているメールでは、問題無く html/プレーンの
切り替えが正常に働きますが、逆の場合はプレーンのみ表示されるようです。

試しに、html で表示できないメールを、テキストエディタで手動で
html パートをプレーンテキストパートの下に持ってきたら、
問題無く切り替えできるようになりました。

何かのバグなのでしょうか？
よろしくお願いします。