続きです。

Bug 1219084 : Some feeds in Thunderbird isn't updated in mac.
のその後をざっと拝見しました。
alta88さんより、「Linuxでは再現しないよ、feeds.rdfも特に問題なくね？」な指摘がありましたので、Ubuntu14.04+Thunderbird38.3.0にてフィードの挙動を確認したところ、確かにLinux上では再現しません。

そして、feeds.rdfの内容が、Macとほぼ同様に

が

の直後に来たものであり、かつ再起動後にも特に問題は出ませんでしたので、「問題ない」と判断された理由はわかりました。

また、問題が再現するフィードと再現しないフィードとを比較してみたところ、既にご指摘ありますように、dc:title=部分に濁音or半濁音が含まれる場合に再現するように思います。

以下確認を取ったフィード一覧（内はdc:title=に含まれる文字列）
Reproductive feeds
http://rss.rssad.jp/rss/slashdot/slashdot.rss
（スラド）
http://www.apple.com/jp/main/rss/hotnews/hotnews.rss
（アップル - ホットニュース）
http://www.mozilla.jp/blog/feed/
（Mozilla Japan ブログ）

No problem feed
feed.php
（MozillaZinejp フォーラム）
http://mozillazine.jp/?feed=rss2
（MozillaZine.jp）
https://mariadb.atlassian.net/activity
（Activity Streams）
http://security-t.blog.so-net.ne.jp/index.rdf
（セキュリティ通信）

各フィードのfeeds.rdfをまとめました（スラドとアップルニュースは散々やったので省きました）。
タイトル一覧
（ubufeeds.rdf以外は全てMac OS X10.10.5環境で作成しています）
ubufeeds.rdf ubuntu14.04にてアップルニュースのフィード検証
mariadb.rdf　mariadbのActivity Streams
mozillajapan.rdf　Mozilla Japan ブログ
security.rdf　セキュリティ通信
mozillazineforum.rdf　MozillaZinejp フォーラム
mozillazine.rdf　MozillaZine.jp

ずっと、「<RDF:Description RDF:about="urn:forumzilla:root">」の位置が問題であるように考えていたのですが、これのみがトリガーではないようです。
例えば、問題が出なかったso-netセキュリティ通信
http://security-t.blog.so-net.ne.jp/index.rdf
のfeeds.rdfを見ますと、
という結果で構造的にはアップルのフィードと同様です。

これらの状況を踏まえ、再現条件についての推測を一部訂正します。
【条件１】
feeds.rdfにおいて、

が

の直後に置かれることがある

【条件２】
【条件１】を満たし、かつdc:title=に含まれる文字列に濁音や半濁音が含まれている場合、Windows環境では、

• フィードの購読設定にてURL情報が空白となる
• フォルダペインのアイコンがfaviconからフォルダのアイコンに変化する

上記２点により、フィードの更新ができなくなる
Linux環境では、【１】【２】双方満たす条件であっても再現しない

【条件３】
Mac OS X環境では、【１】の有無にかかわらず、dc:title=に含まれる文字列に濁音や半濁音が含まれている場合、

• フィードの購読設定にてURL情報が空白となる
• フォルダペインのアイコンがfaviconからフォルダのアイコンに変化する

上記２点により、フィードの更新ができなくなる
（Thunderbird31.xでの挙動を踏まえた推測）

という現象のように思いました。
検証が甘かったために、何だかミスリードっぽくなり申し訳ありません。

問題はこれを英語で言う必要があるということですか・・・

_________________
Thunderbirdの基本を書いています(ずっと発展途上)　とりかごとなり。
基本の操作(画像あり)：バージョン確認　/ セーフモード / 新規プロファイル作成

違います。
フィードアカウント(サーバー設定)のメッセージの保存先が.../Mail/Feedsの時に、
.../Mail/Feeds/SlashDot(or Apple)というファイルを作り(ヌルファイルで可)、
Thunderbirdを再起動し、.../SlashDot(or Apple)をフィード用のメールフォルダーだと認識させ、
フィードの購読で、SlashDot(or Apple)に対して、スラドあるいはアップルのフィードのＵＲＬを指定する、
です。 のようなエントリーが作られます。

「ド」や「プ」の時に、フォルダーを作りに行く時はcomposed formで(多分File Systemのapi経由)、それをmailbox URL形式でfeeds.rdfに書くが、
panecea.datにはPersistentIDが書かれ、再起動時にはそれを使ってファイルにアクセスするのでフィードのデータは見えるが、
PersistentIDから得たファイル名は decomposed formなので(多分Finder経由)、feeds.rdfの中のmailbox URLとは異なり、
それでfz:feedを見つけられない、ということかな？

やっぱり、みんなでよってたかって突っつくと、犯人が自分から出頭してくる(^^)

alta88 からの要請です。
先にファイルを作った時の挙動をチェックしてください。
(1) 英語名のファイル。
新規にフィードアカウントを作る。メッセージの保存先=.../Mail/Feed-2。
「.../Mail/Feed-2/SlashDot」というファイルを作り、再起動し、念のためにもう一度再起動。
「SlashDot」に対してスラドのURLを指定して購読。
Tbを終了してfeeds.rdfの内容をチェック。
(2) 日本語名のファイル。
新規にフィードアカウントを作る。メッセージの保存先=.../Mail/Feed-3。
「.../Mail/Feed-3/スラド」というファイルを作り、再起動し、念のためにもう一度再起動。
「スラド」に対してスラドのURLを指定して購読。
Tbを終了してfeeds.rdfの内容をチェック。

再起動後に問題が起こりますか？
(2) 日本語名のファイルにおいて、feeds.rdfに書かれるmailbox URLが、購読時にtitleからThunderbirdが作った時のものと変りますか？

ファイルの作成方法が間違っていたとのことで失礼しました。

改めてこれを行ってみました。
（１）（２）ともに、フォルダペイン上では予め作成しておいたファイル名と同一になります。
また、どちらであっても再起動後に問題は出ず、正常にフィードの購読、更新が可能になっています。


rdfの詰め合わせを置いておきます。
SlashDot.rdf　（１）の条件で作成
スラド.rdf （２）の条件で作成
sradjp.rdf 従来の方法で作成

（２）で作成した時のmailbox URLは

従来の方法だと、
どちらもフォルダペイン上は「スラド」の表記です。

_________________
Thunderbirdの基本を書いています(ずっと発展途上)　とりかごとなり。
基本の操作(画像あり)：バージョン確認　/ セーフモード / 新規プロファイル作成

ビンゴ。
これで、ファイルシステム上はcomposed formのファイル名の時に、Mac OS XのThunderbirdが、再起動後には(多分、panacea.datのPersistentID経由でアクセス)、 decomposed formの名前からmailbox URLを作り出してfeeds.rdfのfz:feedのアクセスに使っていることが判明。

[追記]
alta88 のパッチは、フィードの中で、入手したファイル名を正規化(normalize)してからmailbox URLを作るように変えています。
これで、File system上の実際のファイル名がdecomposed formであっても対応できるはずだと思います。
[追記おわり]

meeyar さん、(2)の手動で作った日本語名のフォルダーを、メッセージフィルターのメールのコピー・移動先にした時、検索フォルダーの検索対象のフォルダーにした時、
msfFilterRules.dat(サーバーごと)とvirtualFolders.dat(Thunderbird全体で一つ)の中にどちらの形式でmailbox URLが書かれるか、確認してください。
こちらはcomposed formなら、フィードだけの問題。
こちらもdecompsed formだと、Mac OS Xにcomposed form(file system)とdecomposed form(Finder)とPersistentID(Finder)をごちゃ混ぜにされるときちんと対処できない、という現象の一つになると思います。

また、panacea.datをテキストエディターで覗いて、(2)の手動で作った日本語名のフォルダーに対してどのようなエントリーが作られているか、確認していただけますか？
WinやLinuxだと、フォルダーペインのフォルダーの表示名⇔ファイルの絶対パス、がかかれます。

Winでのpanacea.datの内容を貼り付けておきますね。
フィードの「スラド」と、ローカルフォルダの、Trashと、ファイル名=Unsent Messages、フォルダーペインの表示とは異なりローカライズはされないフォルダー名=Outbox、が見えています。
panacea.datでは、8bits-binaryを$XY(X,Yはヘキサデシマル)でエスケープしていて、バックスラッシュはバックスラッシュでエスケープしてます。

それぞれ調べたので書いておきます。
msfFilterRules.datのactionValue。

virtualFolders.datのuriとscope。

panacea.datの中身。

すべてfeeds.rdfと同じ表記です。

_________________
Thunderbirdの基本を書いています(ずっと発展途上)　とりかごとなり。
基本の操作(画像あり)：バージョン確認　/ セーフモード / 新規プロファイル作成

meeyar さん、確認ありがとうございます。

msfFilterRules.datのactionValue。
virtualFolders.datのscope。(検索フォルダーそれ自体)virtualFolders.datのscope。(検索対象)どれも、Finderから渡されるdecomposed formを正規化せずにそのまま使っているようですね。
夫々の機能の中で統一されていて、Feedのように、タイミングによって食い違いがでるようなことはないと思いますが。

panacea.datの中身。
フォルダー関連のファイル名については、Finderから渡されるdecomposed formを正規化せずにそのまま使い、panacea.datには、Linuxと同様に絶対パスを保存しているみたいですね。

いくつか勘違いがあったので訂正します。
(1) Mac OS X でも、panacea.datに絶対パスを保存している。
(2) HFS+では、ファイルシステムが"decomposed form"でファイル名を保持している。
　 http://wiki.bazaar.canonical.com/UnicodeSupport
　　Mac OS Extended (HFS+) - the default and recommended file system
　　- uses canonically decomposed Unicode 3.2 in UTF-16 format.
(3) Mac OS XのThunderbirdは、メールフォルダーに関して、内部的にはファイルシステムから渡されるファイル名をそのまま使っていて、それを表示名にする時とか表示する時に、composed formにして表示している。

Mac OS Xでフォルダー名関係の問題の時に、もっと早くにmsgFilterRules.datやvirtualFolders.datやpanacea.datの中身を見せてもらっておくべきだった...
ウムラウトととかアセントとかで何かおかしくなる、というようなバグは、結構よく開かれる...
でも、ターミナルを開いて云々とか言っても、通じないことも多い...(^^;

経過報告です。

[現象と原因]
(1) 新規に購読した時に、FeedsUtilsでは、dc:titleから"composed form"のファイル名を作り、
そのファイル名でファイル・メールフォルダーを作り、
"composed form"のファイル名からmailbox URLを作ってfeeds.rdfに書き出す。
(2) HFS+のデフォールト(かつ推奨)では、ファイル名は"decomposed form"で保持され、
それがそのまま「ファイル名」としてアプリケーションに提示される。
(3) 再起動後は、その、Mac OS X から渡された"decomposed form"のファイル名からmailbox URLを作り出し、その"decomposed form"のmailbox URLでfz:feedのエントリーを探すので、見つけられない。

「現時点の alta88によるパッチ」
(1)の時点で、dc:titleから作り出した"composed form"のファイル名を正規化して"decomposed form"のファイル名に変えてからファイルを作成し、"decomposed form"のmailbox URLにしてfeeds.rdfに書く。

「現時点の alta88によるパッチの問題点」
でも、たとえデフォールト(推奨)であっても、HFS+の"decomposed form"か"composed form"かはオプションのはずで、その修正では、ユーザーがHFS+に対して"composed form"を選択した場合には対処できない。

WADA様、拙い英語でBugzillaへ報告したのは私です。
大変なお手間深謝いたします。
Bugzilla以降、時間があまりなくこちらは見なかったのですが、Bugzillaのやりとりを参考に
とりあえず、誰でもできる回避方法がありますので、フィードリーダーとして必要な人は参考にしてください。

今まで登録したフィードを完全に削除できない場合は　~/Library/Thunderbird/Profiles/xxxx/Mail/ 内に
デフォルトなら Feed*** というフォルダ内に該当のFeedがありますのでそれを削除か、ファオルダ毎削除して
フィードアカウント自体を新しく一から登録しましょう。

どうも、Macの日本語環境で、タイトルに濁点か半濁点があるとそのようになるようです
私の抱えるフィードを全て公開すればもっと早く見つけられたかもしれません。私も想定外でした。

1.フィードの購読画面で、URL入力
2.「追加」ボタンを押下
3.タイトルを濁点、半濁点のないものに変更
4.「閉じる」ボタン押下

でとりあえず回避はできるようです。そこのフィールド内からフォルダ、ファイルを生成するようで、それがHFS+の仕様上、OSレベルで修正があり、それが合致しなく整合が保たれないということのようだと思います。ですので、それでもうまくいかない場合タイトルの部分をいろいろ工夫してみてください。

システム依存の部分や日本語固有のようなので、OS間の互換性を保つ為Thunderbirdでの修正はすぐにはないかもしれませんので、しばらくはユーザーレベルで対応いたしましょう。

_________________
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:41.0) Gecko/20100101 Firefox/41.0

でも、フィードを購読しようとURLを入力した時点ではサーバーにアクセスしていないから、タイトルフィールドには何も表示されないんだよなぁ...
だから、購読して、再起動したら、フォルダーアイコンは消えるは更新はされないはURLは消えるは、で、で思いっきり悩んだ後、フォルダー名やfeeds.rdfの中のデータに濁点や半濁点やウムラウトやアセントやタミル語の文字などがあることに気づき、グーグル検索したりQAフォーラムなどで聞いて、ようやくフォルダーを削除して購読し直してタイトルに安全な文字だけを入れる、ということになる。

タイトルを変えるのなら、最初から、常に安全な英数字記号だけでタイトルを指定して購読(==ファイル名は自分で指定)、を習慣にした方が、悩むことが少なくて済む分利口かも。
昔のMacだとフリーズやクラッシュしない方がおかしいから、折角入力したデータが全部消えてしまわないように、Command+Sが何かを理解していなくても、無意識のうちにCommand+Sを一分ごとに叩けるようにするのがお約束だったように(^^)

でも、それならば、フィードのフォルダー名リネームの方が、シンプルでわかりやすくて利口。
(1) アップルのフィードを購読。
(2) 購読後にタイトルを「ABCDE」に変更 ⇒ dc:title が変るのみ。
(3) フィードのフォルダー名を「VWXYZ」にリネーム
　　⇒ ファイル名が変り、それに応じてmaibox URLが書き換えられる。

WADA様

一度「追加」ボタンをクリックするとタイトルのフィールドにWEBから読み込んだタイトルが表示されますよ。
その時点で任意の名前に変更して、「閉じる」ボタンをクリックすると一応回避できます。
それが一番手順としてはやりやすいかなと。

_________________
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:41.0) Gecko/20100101 Firefox/41.0

「追加」の段階では、まだフォルダーを作ったりfeeds.rdfの更新には行かなくて、「閉じる」で作りに行くんですね。
「追加」で作って、「閉じる」はウィンドウを閉じるだけだと思っていました。