There are no current plans. I can say, having watched the progress of this as a member of the release-testers group - and seeing the pain it causes in for example the reanimated module, that it looks quite expensive to me, on the "module maintainership" side. So that's a negative: very high cost in new tech integration as it brings in new toolchains and requires module release cadence to sync with react-native release cadence - a significant new hurdle for all library consumers and a significant new dependency for release cycles.

(削除) If I understand correctly the sole benefit is that it is a performance optimization (削除ここまで) [Edit: this explains the benefits better, I'm still not sure they really apply to react-native-firebase, but it is important to understand them:https://github.com/react-native-community/discussions-and-proposals/discussions/546#discussioncomment-4160151 ]

In our case, I'm not sure there is any actual benefit to it for performance improvements with the exception of firestore, which could benefit perhaps from better performance in data marshalling/unmarshalling. But then it is my understanding that most of the performance issues people have had with firestore are related to local cached data being accessed slowly due to underlying issues in the native SDKs.

So to me I see large costs + a lot of added complexity and I see very uncertain benefits. Thus I haven't put it on my short list of things todo personally

Side note is that our testing infrastructure requires the JSI interface and I'm not sure that works when Fabric is enabled. So if I understand correctly, this is blocked until our e2e infrastructure moves to a pure on-device solution - that's something we have in progress but it's not done yet.