ChromeがJetpackをサポートしたらどうしよう

ChromeがGreasemonkeyをサポートしてしまいました。

Bibliwoを書いてて、1000行超(データを含めたらもっと沢山)のuserscriptってちょっとどうよ……ええかげんFirefox拡張として書くべきと違うんか……と思うこと甚だしかったのですが、Firefoxの現行の拡張の仕組みは将来的に縮小(なくなりはしないけど基本Jetpack)、ChromeはGreasemonkeyサポート、という誰も予想しなかったであろう状況になりつつあります。
userscriptをJetpackに書き直すのはごく簡単なので(例えば、簡単な修正を加えることでBibliwoは手元ではJetpackとして動かせてる)、userscriptとして書いておけば将来的にFirefoxでもChromeでも拡張として動かせる! Greasemonkeyこそブラウザ拡張の中心的技術だった! Bibliwoも無理にFirefox拡張に書き直さなくて良かった!と安堵しております。

グリモンが簡単にChromeで動いてしまったのは、グリモンのAPIが数少なくて安定していたのが一つの原因でしょう(難しいAPIは未だサポートされてないけど……クロスドメインXHRやset/getValueは、セキュリティ的にあえてサポートしてないという気もしてきた)。。
安定的なAPIを提供すると言えば、それはJetpackのプロジェクト目標でもあります。あれ、ということはJetpack正式リリースの暁には、ChromeがJetpackをサポートしちゃう可能性もあるのでは?
現に、現在提供されている/提案されているJetpackのAPIで、Firefox特有でChromeでのサポートが難しそうなものは少ないです(JEPのGadgetは微妙。XULRunnerと密な連携をするものは当然ダメ。でも大抵の拡張はここら辺使わないでしょう)。

もしChromeがGreasemonkeyのみならず将来的にJetpackをサポートしてしまい、大抵の拡張はChromeでもFirefoxでも動くようになってしまったら、みんなどっちを使うんでしょうかね。
JetpackはなるべくXPCOMなどへの直接的なアクセスを排除するような方向で開発されつつあるようですが、Mozilla生き残りのためにあえて移植性を低くするような設計にしてしまうという可能性もなきにしもあらずなのかなぁ、という陰謀史観(その場合、高度な機能を実現する拡張のためにXPCOMへのアクセスは残すべきだみたいな建前の下に、実際にはXPCOMへのアクセス無しにはろくな拡張が作れないようにしてしまうのが良いんじゃないでしょうか)。