わざわざスクリーンショットを貼り直していただき、ありがとうございます。余分なお手間を取らせてしまって申し訳ないような...。

拝見しました。[フィードの購読] ウィンドウの基本構造は、当方の Windows 環境のそれと変わりません。
子階層の [フィードの URL] がないと、アクセス先が特定できないためフィードの更新ができなくなるのは、すでにみなさんからご指摘があるとおりです。
しかし下記の状況だとしたら、何がどうなっているのか、ちょっとわかりかねます。

（中略）
お示しくださった内容を拝見する限り、ぼくも「ぱっと見は特に問題がありそうには見えません」に同意します。

ご承知のことと思いますが、Thunderbird のフィードアカウントにおいて、[フィードの購読] ウィンドウにある [フィードの URL] が保存されているのは feeds.rdf です。prefs.js その他には保存されていません。
prefs.js には、フィードアカウントをメールアカウントと同様に扱うための情報だけが記述され、[フィードの URL] などの中枢情報は ～ <profile>\Mail\Feeds 内に集約されています。
厳密には、feeditems.rdf にもフィード URL の記述はありますが、これは個々のフィード URL に対して受信済みのアイテムを識別するためのもので、[フィードの購読] ウィンドウにある [フィードの URL] を直接定義しているものではありません。仮に、feeditems.rdf に異常が起こった場合、すでに受信済みのフィード記事を何度も受信してしまうといったことは起こりそうですが、未受信の新規フィード記事を受信しなくなることは、ちょっと考えにくいように思います。


Thunderbird を起動中に、新しいフィードの購読先を追加したり、OPML からインポートしたときは正常に動作し、いったん Thunderbird を終了して次に起動したとき、[フィードの URL] が消えている購読先がある ―― ということは、次のように考えられます。
（1）再起動前は、新規作成またはインポートしたフィード情報がメモリ上に読み込まれているので正常に動作している。
（2）再起動後は、それらの情報が feeds.rdf から読み込まれるため、feeds.rdf に異常が起こっていれば、[フィードの URL] などを正常に読み込めないことがありうる。
―― という解釈です。

feeds.rdf の異常については、
（a）feeds.rdf そのものに異常が起こり、[フィードの URL] が消失している。
　　（a-1）フィードの更新時、または Thunderbird 終了時の feeds.rdf の更新が不正常。
　　（a-2）アドオンの誤動作、または何らかの外部要因が、feeds.rdf を書き換えてしまう。
（b）feeds.rdf の内容は正常だが、起動時に feeds.rdf を適切に読み込めない。
　　（b-1）一部の設定ファイルの読み込みに関して Thunderbird（とくに Mac 版）にバグがある。
　　（b-2）設定ファイルの読み込みに際して、アドオンなどが不適切な干渉をしている。
―― などが考えられます。（ただし、その他の要因や、複数の組み合わせで起こる可能性も、視野に入れておいてください。）

（a-2）のアドオンの誤動作と（b-2）は、KTBN さんの 2015年10月24日(土) 13:41 付けの投稿（p56310）を見る限り、可能性は低いと思われますが、「feeds.rdf の異常」という観点での点検がきちんとおこなわれたわけではないので、可能性のひとつとして挙げてあります。

当初、提示された情報から、feeds.rdf が不適切に書き換えられている可能性、とくに（a-1）を疑ったのですが、meeyar さんがお示しくださった内容を拝見する限り、不可解なところには気づきませんでした（見落としているだけかもしれませんが...）。
しかも、正常な [フィードの URL] もあるということは、消えてしまう [フィードの URL] と何らかの差異があるということですから、このあたりの切り分けを進めてみないことには、ちょっと見通しが立たない気がします。

これもご承知と思いますが、確認を兼ねて書きます。
Thunderbird の起動中にフィードの更新（アクセスと読み込み）が実行されれば、feeds.rdf と feeditems.rdf も更新されます。

feeditems.rdf は受信済みのアイテムを記録して重複受信しないためのものなので、フィードの更新のたびに内容が変わります。

feeds.rdf は、[フィードの購読] ウィンドウでユーザーが設定内容を変更したとき以外、内容的な変化はありませんが、購読先の順番が入れ替わることがあります。
<fz:feed RDF:about="<フィードの URL>" ～ から始まり、</fz:feed> で閉じられるブロックを単位に、順番が変わっていることがあるわけです。
このあたりの理由はよくわかりませんが、複数のフィードがある場合、受信時に「逐次」ではなく「並行」したアクセスがおこなわれ、通信が成立した順番に feeds.rdf が書き直されるようなことがあるのかもしれません。
しかしブロック単位の順番以外、[フィードの URL] をはじめ記述内容が欠落したり、別の内容に書き換えられることはありませんし、フィードの更新が効かなくなることも経験していません。

feeds.rdf の書き換え時に問題が起こっているケース（上記 (a) ）をさらに調べつつ、feeds.rdf は正常だが読み込み時に問題が起こっている可能性（上記 (b) ）も考えたほうがいいかもしれません。
いまの段階では断定できませんが、Mac 版の Thunderbird 38.x 系に何かしらのバグが入り込み、改行コードなどの制御文字を含めて文字列の処理に部分的な不具合が起こっていて、その結果 feeds.rdf の読み込みが正常におこなえないケースがあるのかもしれませんから。

ストレートに解決に結びつく話ではありませんが、以上です。

_________________
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0

[ code ] ブロックでも、長いと < br > を入れてしまうみたいなので、思いっきり端折ったもので大まかな構造を示しておきます。

Winで、新規にフィードアカウントを作り一つだけ追加しただけのもの。


「MozillaZine.jp以外は再起動後に更新できなくなってしまいます」というfeeds.rdf。

Winで新規に作ったものとの違いでちょっと気になるのが、
(1) MozillaZine.jpのfz:feed だけが、RDF:RDF ... xmlns:fz="urn:forumzilla:"でポイントされている、RDF:Description RDF:about="urn:forumzilla:root"から始まるグループの外にある。
(2) RDF:Description RDF:about="urn:forumzilla:root" <fz:feeds RDF:resource="rdf:#$fcsyk1"/> の後ろにRDF:Seq RDF:about="rdf:#$fcsyk1"が定義されている。

(2)のせいだとすると、全部のfz:feedを見に行けなくなりそうだから、(1)が関係する？

RDF:Seq RDF:about="rdf:#$fcsyk1"の中の最初のMozillaZine.jpのfz:feed を見に行った後、RDF:Descriptionなどの定義の場所などとの関係で他のもののfz:feedを見つけられない、といった問題が考えられます。
Mac OS XのXMLのパーサーの問題かもしれません。
あるフィードを追加しようとするとそれ用のfz:feedが既にあるからできない、というのは当然でしょうね。

MozillaZine.jpのfz:feedの場所を変えてみる、RDF:Seq RDF:about="rdf:#$fcsyk1"の中の順番を変えてMozillaZine.jpのものを最後にする、などをしてみると、違いがでるかもしれません。

提示されていたfeeds.rdfの内容に書き換えて遊んでみたら、同じように、アイコンが普通のフォルダーになり、購読にURLがでなくなり、あわててfeeds.rdfに元あったfz:feedを追加してみたりpanacea.datを消してみたりしたのだが、二度と元に戻らなくなってしまった(^^;

購読で表示されるURLは、feeds.rdfから持ってきているわけではなさそうです。
feeds.rdfの内容を壊すとおかしくなるから、読みに行っていることは確かですけど。
基本的には、登録の時に使い、登録した結果を保存してある、という感じです。
アイコンが変るのは、登録や更新時に「フィード」というフォルダーの属性がセットされるが、まともなフィードではないと判断されると「フィード」というフォルダーの属性がクリアーされる、というだけ。

panacea.datあたりに保存かな。(フォルダーキャッシュ)
panacea.datを消すとFeedで問題が起こる、というようなバグがあったような気が...
で、WinとLinuxでは絶対パスを書くが、Mac OS XではPersistent-IDといったようなものを書いたはずで、prefs.jsの最後に保存したディレクトリーなども同じだったはずだし、server#.directory-relに対応するserver#.directoryの内容もPersistent-IDかもしれません。
Unix系のファイルシステムの絶対パスとFinder系のものの両方が使われていて、どこでどちらが使われるかは、その時のMac OS XとThunderbirdの気分次第(^^)
このあたりが絡む現象かもしれません。
panacea.datをテキストエディターで覗いて、問題の無いフィードのエントリーを見てみると、何かわかるかな？

このようにいうのは、フィードに関して昔いろいろ試した経験をふまえています。本トピックに投稿するにあたり、Windows 環境の Thunderbird 38.3.0 でも再確認しましたので、そのあたりを書きます。

feeds.rdf では、<fz:feed RDF:about="フィードの URL" ～ </fz:feed> のブロック内に、ひとつの購読先フィードの情報がまとめられているようです。
このうち、dc:identifier="フィードの URL" にある URL を書き換えると、Thunderbird の [フィードの購読] ウィンドウにある [フィードの URL] に、書き換えた内容が反映されます。例えば、dc:identifier の URL を削除すると、[フィードの購読] ウィンドウにある [フィードの URL] は空欄になります。
このことから、[フィードの購読] ウィンドウにある [フィードの URL] の内容がどこから読み込まれているかを推定しました。

しかし、この部分を変更しただけではフィードアカウントのフォルダは変化しません。アクセス先情報が狂うのでフィード記事を受信できなくなりますが...。

フォルダが変化するのは、<fz:feed RDF:about="フィードの URL" ～ </fz:feed> のブロックが丸ごと消えるか、その構造が壊れた時でした。
ただし、受信済みのフィード記事は問題なく表示されます。これは、メールアカウントの構造と同じように、フィード名と同じ拡張子のないファイルに、フィードコンテンツの実体があり、Thunderbird はそれを認識しているからだと推測しています。

Mail\<account> フォルダ配下にある拡張子のない（あるいは特定の拡張子以外の、というべき？）ファイルが、Thunderbird 上では自動的にフォルダとして認識されるというのが、Thunderbird の統括的なフォルダ管理の仕組みのベースだと思いますが、これに加えて特定の属性を付与してフォルダアイコンを変化させたり、属性に見合った動作をさせる仕組みがあるのだと思います。
フィードアカウントでは、feeds.rdf の <fz:feed RDF:about="フィードの URL" ～ </fz:feed> が、そのフォルダがフィードの性質を有していることを定義づけているように思いますが、それを受けてフォルダアイコンを変化させているのは、メールアカウントと同じ仕組みなのだろうと思います。

このようなわけで、本トピックの主題である、フィードが購読できなくなる、フォルダアイコンが変わるという問題を探る上で、まずは feeds.rdf に着目しました。
ただ、feeds.rdf に対して具体的に何が起こっているのか、feeds.rdf は無関係で他に原因があるのか否か、そのあたりはわかりません。

_________________
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0

再現性がわかりましたので書いておきます。
やはりfeeds.rdfの記載内容が鍵となるようです。

前回のfeeds.rdfは複数のフィード詰め合わせでしたが、実際には1つのみの登録でも再現します。却って混乱を招いたようで申し訳ありません。
Appleのフィードのみを登録した時のfeeds.rdfをWindowsとMac OS Xとで比較してみました。

Windows環境ですと

ですが、Mac OS Xですと最後尾の

の記述が、冒頭の

の直後に来ています。

diffの結果

スクリーンショットも貼っておきます。
OS Xでのfeeds.rdf内容でWindows環境に置き換えると、Windowsでもフィードのfaviconがフォルダのアイコンに変化し、フィードの更新ができなくなります。


(1)のご指摘がどんぴしゃで、OS X環境では、feeds.rdfにおいて「RDF:Description RDF:about="urn:forumzilla:root"から始まるグループ」の内側にfz:feedを持ってきてしまい、これが原因でフィードの更新がおかしい、という風に見えます。

ただ、OS Xでもフィードの種類によって、fz:feedの位置が変わる理由がわかりません。
再現性について「フィードの順番が関係するのではないか」というご意見もありましたが、登録順・表示順によらず、大丈夫なフィードと問題が出るフィードは決まっているようです。

それともう一つ、feeds.rdfの中身は再起動の前後で同一にみえるので、何故登録直後は大丈夫なのかも謎です。初回から問題が出てもおかしくない気がするのですが。
初回はフィードの設定画面から直接フィードを更新→feeds.rdfを読み込まない→再現しない
とかでしょうか。

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

説明に基づき、
fz:feeds RDF:resource="rdf:#$fcsyk1"という、個々のフィードの定義へのポインターを持っているエントリーへのポインター、
RDF:Seq RDF:about="rdf:#$fcsyk1"という、個々のフィードの定義へのポインターを定義しているエントリー、
fz:feedという個々のフィードの定義、
の位置関係を変えて整理したら、無事に復活しました(^^)

(1) フィードの購読では、やっぱり、feeds.rdfを常にちゃんと見ていた。
(2) feeds.rdf内の定義の順番によっては、見つけられない fz:feed RDF:about="フィードのURL" が発生する。
(3) Mac OS X では、フィードによっては(2)の問題が起こる順に書くことがあるが、Winでは(2)の問題が起こらない順に書く。
という感じですね。

私のところでおかしくなってしまったのは、Mac OS Xで作られた、問題が起こる順に書いてあるfeeds.rdfを使ったせいで、panacea.datは無罪だったようです。

みんなでよってたかってつつくと、思ったよりも簡単に犯人を炙り出せるみたいですね(^^)

meeyar さん、WADA さん、お疲れ様です。
お二人のおかげで、feeds.rdf の中で起こっていることがわかりました。

あとは、なぜ Mac 版の Thunderbird で起こるのか、ですね。
現状では、OS X のバージョンには関わりなく Mac 版 Thunderbird 38.x で起こっているようですし、破損した feeds.rdf では Windows 版 Thunderbird でも同じ問題が発生するようです。
feeds.rdf は、Thunderbird を起動してフィードを受信するたびに書き換えが発生しますから、そのときに問題が起こるのかもしれません。

KTBN さんの報告を見ると、以前は正常に購読できていたフィードが、あるときから購読できなくなったようです。
一時的に前バージョンの 31.x を導入してフィードの動作を試せれば、Thunderbird のバージョンの違いで本件の症状に差があるか否か明確になると思います。
そのあたりがはっきりすれば、Mac 版 Thunderbird 38.x のバグってことで決まりでしょう。

この投稿の前に Bugzilla を見たら、次のバグ報告が 2015-10-27 付けで上がっていました。
・Bug 1219084 - Some feeds in Thunderbird isn't updated in mac.
https://bugzilla.mozilla.org/show_bug.cgi?id=1219084

このあとの進展を期待したいところです。

（補足）
さらに欲をいえば、当面の回避策でもあればいいのでしょうけど、Thunderbird の中でもフィードの扱いはちょっと特殊なので、メールアカウントのように about:config にある何かの設定項目をいじって……といった回避策は期待できそうにありません。
ベータ版（現時点で 42.0b2）などの開発バージョンで回避できるのなら、当面はフィードアカウントだけそれで逃げる、ってのもアリかもしれませんけど...。

_________________
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0

meeyarさん、偶然的通行人さんが見つけたバグに、Macのfeeds.rdfとWinのfeeds.rdfをアプロード(add attachment)しておいていただけますか？
フォルダーパスが同じになるように、「mailbox://nobody@Feeds-3/」のところは「Feeds-2」に書き換えた方が親切。

まだ何もあきらかになっていなくて、WinとLinuxでしか追試していないので、デバッグをオンにしてログをとれ、さもなくばINCOMPLETE、とか言ってます。

FYI.
RSS Feedのモジュールの多くはFeedUtils.jsmに定義されています。
以下は、feeds.rdfのテンプレート。
この構造を期待しているはずです。

http://mxr.mozilla.org/comm-central/sou ... s.jsm#1057

最初の一つのfz:feedを新規に追加しただけで起こるから、あるURL用のfz:feedを追加するときに、<RDF:Description about="urn:forumzilla:root">～</RDF:Description>のブロックの中の更新と同時に、このブロックの中に書いてしまうのかな？
Mac OS Xだとmulti-cpu/multi-taskingが有効に動きすぎて、常に順番に実行されることを前提のコードでは破綻する？

僅か1日で話が進んでいてびっくりしました。
「Bugzilla報告案件っぽいけど英語だし…」と思っていた矢先。
一応パスをそろえて、それぞれのfeeds.rdfとdiffをuploadしました(Comment3以降)。英語に全く自信がないのですが、あんな感じでよいのでしょうか？

いつからの不具合なのか、ということにつきまして、

Thunderbird31.8.0で調査してみました。
新しくフィードの設定をしてみると、Windowsと同じように「 <RDF:Description RDF:about="urn:forumzilla:root">」以下の記述が末尾についた、
という記述なのですが、再起動すると更新できなくなります。また、再起動の前後でfeeds.rdfの記述に変更は無いようです。

• 31系と38系とでは問題の発現機序が異なる
• feeds.rdf以外にも問題を抱えた箇所がある

といった可能性がありそうな印象です。
（24以前のバージョンまでは確認しておりません）

また、38.3.0において、「Macのfeeds.rdfをWindowsへコピー→再現性あり」なので、逆をやると改善する？　と期待し、「Windowsのfeeds.rdfをMacへコピー」をしてみましたが、残念ながら改善されませんでした。
一度購読が外れてしまうと、単純なrdfファイルの差し替えでは治らないようです。
このことからも、rdfファイルの他にも本Bugの再現要因がありそうに思います。

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

バグを開いてくれたのはKTBNさん？
meeyar さん、feeds.rdf のアップロードありがとうございます。

alta88からの要請。
Feeds.logging.console = debug (多分)にして再起動してコンソールログをとる。

[追記]
日本語のファイル名だと解析しにくいし、ファイル名が関係する可能性があるので、
新規のフィードアカウントを作ってTbを終了し、
Apple と SlashDot というファイルを作ってThunderbirdを再起動し、
そのフォルダーの購読で、アップルとスラドのURLを指定。
(フィードのtitleは、購読した時にファイル名を決めるためだけに使われるそうで、メールフォルダー用のファイルの名前と同じだから、以降は変えられることはないそうです。だから、先にファイルを作ってしまえば、こっちのもの)
[追記おわり]

一つだけで確実に再現できるフィードをもう一つ提示しておいた方がいいかも。

問題が起こるというフィード。

ユニークIDの割り振りに使う「URL」と呼んでいるものは、実は「dc:title」で、「ド」とか「プ」があると、composed form とdecomposed formの違いでうまくいかない？
ファイル名はtitleからもってくるみたいなので、ファイル名⇒feeds.rdfのエントリーの変換ができない？
こういったことだと、Mac OS Xだけというのは肯ける。

meeyar さん、WADA さん、Bugzilla への対応、お疲れ様です。

meeyar さんの検証結果を拝見すると、仰っているように何かしら未知の要因が潜んでいそうですね。

当方、自由に使える Mac 環境がないため、この先は役に立てそうもありません。
meeyar さんと WADA さんさんにばかり労力を強いることになっては心苦しいのですが、次のあたりが少し気になりました。

テスト用に共通の条件で構築した、Windows と Mac それぞれのフィードアカウントにおいての話です。

本件の問題が発生した Mac 環境のフィードアカウントにある feeds.rdf だけを、Windows 環境で正常に動作している feeds.rdf で置き換えても、
（a）問題の起こっているフィードは相変わらず受信できない（[フィードの購読] ウィンドウにある [フィードの URL] は空欄になる）
（b）通常のフォルダ表示になってしまった状態もそのまま（本体のフィードアイコンに戻らない）
―― ということでしょうか。

• Windows 、Mac 双方の、Feeds フォルダ配下にある feeds.rdf を含むすべてのファイルを、一括して Win -> Mac で置き換えても同様ですか。
• Mac 環境で、問題が起こったフィードアカウントとは別にフィードアカウントを作り、そこに Windows 環境で正常に動作している Feeds フォルダ内のすべてを一括してコピーした場合、どのような動作になりますか。初回起動時、それ以降で変化はありますか。
• feeds.rdf の構造自体に変化は見られなかったとして、Mac 環境における feeds.rdf の文字コードや改行コードに変化はありますか。

上記をふまえ、

• feeds.rdf が不正常に書き換えられるということの他に、Mac 版 Thunderbird が feeds.rdf をどのように読み込んでいるか
• フィード購読の中枢を担う feeds.rdf 以外の部分で、本件に影響している要素はあるか

とったあたりを探ってみることは、できますでしょうか。（やはりデバッグをおこなうほうが早いのかも？）


"Unicode の正規化" の影響ってことですか。たしかにその可能性はあるかもしれませんね。他にも、


という結果なので、"Mozilla Japan ブログ" も更新できくなることにも整合性のある説明がつきます。

ですが、まだ疑問も残ります。
meeyar さんが提示された feeds.rdf のソースを拝見する限りでは、「プ」や「ド」が分解されて「フ」＋半濁点、「ト」＋濁点 になっているようには見えません。この場合は、feeds.rdf の書き込み時にではなく、読み込み・解釈の時点で起こる問題なのかな？

また、"Unicode の正規化" それ自体は、以前の Mac OS X からおこなわれていたはずなので、

という話とは、かみ合わないような気がします。
KTBN さんが "閲覧できていた" と仰っている時点の Thunderbird のバージョンが定かではありませんが、meeyar さんのテストによれば Thunderbird 31.8.0 でも起こったというお話なので、そのあたりの時期に OS X でおこなわれた何らかの変更が、トリガーになっている可能性もありえるかもです。

もし、"Unicode の正規化" が影響しているのだとしたら、[フィードの購読] ウィンドウの [タイトル] 、または feeds.rdf の dc:title を直接書き換えて、問題が再現するかどうかをテストすることはできると思います。（"Mozilla Japan ブログ" => "Mozilla Japan Blog" とか）

Bugzilla でコメントを付けている alta88 さんも Windows や Linux では異常がないと書かれているので、やはり Mac 環境固有の問題ではあるのでしょう。

Mac 版 Thunderbird でフィードを購読しておられる他のユーザーさんたちから、情報提供や動作検証の報告があればいいのですが......。

力になれなくて申し訳ありませんが、以上です。

_________________
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0

私が行ったのはこの逆。
Windows 環境で正常に動作している feeds.rdf だけを、本件の問題が発生した Mac 環境のフィードアカウントにある feeds.rdfで置き換える。

(1) あるフィード(FeedXとします)だけがある時に、
(2)「MozillaZine.jp フォーラム」しかちゃんと見えない、というMacのfeeds.rdfで置き換えたら、
(3)FeedXの定義を消してしまったんだから、FeedXは壊されて当然で、
(4)その他のフィードのfz:feedが全部のところに、FeedXのfz:feedを追加し、
　　RDF:Seq RDF:about="rdf:#$fcsyk1"にFeedXのエントリーを追加したがダメ。
(5)で、FeedXのfz:feedを含むその他のフィードのfz:feed全部を、<RDF:Description RDF:about="urn:forumzilla:root"><fz:feeds RDF:resource="rdf:#$fcsyk1"/>
</RDF:Description>の前に持っていったら、無事回復。
(6) RDF:Descriptionのブロックの中に、個々のfz:feed以外のRDF:Seqのブロックも入れる、などをすると、構造がもっと綺麗になる。
といった感じです。
この時は、panacea.datを消す、などもしていますから、それが関係するかもしれません。
feeds.rdfを色々と書き換えて遊んでいると、アイコンが消されてURLも消されるとか、アイコンは残るがURLが消えるとか、いくつかのバリエーションがでてきます。
たまにfeeds.rdfを壊して、アイコンもURLもでなくなる(^^;
再起動時にpanacea.datからフォルダーにアクセスできる場合は、mailbox URLからfz:feedが見つかりさえすればいい、とかがあるかもしれません。
フィードのデータはメモリー上に持っていて、更新があったものについて定期的にfeeds.rdfに書き出す、ということをしているそうなので、その時点のフィードの更新の有無も関係するかもしれません。

RDFだから定義の順番は関係ないはずだけれど、個々のfz:feedが定義されるよりも前に個々のfz:feedへのポインターが定義されると、ポインターを辿って行く場合にfz:feedを見つけられない、という感じがします。
[追記]
通常は、feeds.rdfのfz:feedのURLを書き換えて再起動すると、フィードの購読でのURLも変ります。
これは、RDF:Seq の中のエントリーのfz:feedへのポインターを壊しても同じですから、通常は、フォルダーURI(mailbox URI)からz:feedのURLを見ていると思われます。
[追記おわり]
alta88は、Linuxでテストしていて、LinuxのXML/RDFパーサーは出来がいいから問題を再現できないのかもしれません。

titleから作ったファイル名のUnicodeの正規化の話は、alta88が英語名のファイルでテストしろ、と言って来たので、Mac OS X特有の問題だから、あるとすれば、Unicodeの正規化(composed formとdecomposed form)くらいかな、という話。
feeds.rdf内のエスケープされたmailbox URLは、フォルダーファイルにアクセスするためのもので、文字列はファイル名で、" - "の前のUTF-8の3バイトコードの数は「アップル」の文字数と同じだからdecomposed formであるはずもなく、そのmailbox URLでフォルダーファイルにはアクセスできていてフィードのデータにはアクセスできているんだから、関係ないはず。
英語のファイル名で、というのは、alta88に変な方向に行ってもらわないため。

Mac OS Xを使っている方に、単に更新がなされないだけで購読のURLは表示されているのかどうか(MozillaZine.jp フォーラムしかちゃんと見えない時の、その他のフィード)、アップルのフィードのようにURLも消されるのか、アイコンはどうなのか、コンソールログに何が書かれるか、その時のfeeds.rdfの内容やThunderbirdを終了してfeeds.rdfの内容(順番や構造)を変えた時の結果、などを報告してもらわないと、何も進まないでしょうね。
alta88は、再現できないからINVALIDかWORKSFFORME、と言っています。

やり残したものもたくさんありますが、とりあえず行ってみたものについてだけ書いておきます。

皆さまご依頼のdebugについてですが、

にしてはみましたが、方法が適切かどうかの自信がありません。

以下の方法であっていますでしょうか？

1. Thunderbirdのabout:configにてFeeds.logging.console = debugにし、再起動して新しくフィードの設定を行ってみる
2. 一度Thunderbirdを再起動する
3. フィードの様子を確認し、Thunderbirdを終了させる
4. OSのコンソール（コンソール.app）からThunderbirdの表示があるものを検索する

一応行ってはみたのですが、Feeds.logging.console = debugにする前（規定ではinfo)の記録と基本的には変わらないように見えました。フィードの設定を行う・行わないに関わらず、Feeds.logging.console = infoの時も、debugにした後も、

の繰り返しです。


これを行っても問題が再現します。
「フォルダの購読」というのは、アカウント設定において「メッセージの保存先」を「プロファイルフォルダ/Mail/Feeds-X/Apple(またはSlashDot)にする、という意味でよいでしょうか？
以下のスクリーンショットは、アップルのフィードを購読後再起動し、スラドのフィードを登録した直後です。
フォルダ名は先に作っておいたものとは一致せず、フィードの名前（日本語名）がそのまま表示されてしまっています。
この時のアップルニュースのフィードは、以前のスクリーンショットと同様でURLが消えた状態です。
次便とも関連しますが、当方で確認したフィードのうち、再現性があったものについては全てURLとアイコンが消えてしまっています。

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