Consider deprecating old facades #2246
Description
The various libraries in facades have been around for a very long time, and exist only to support code that was built against quite old versions of Rx.NET.
Release new versions of them doesn't add new capabilities: old code is likely not to notice or care if these don't get updated. So we should consider no longer building new ones. And maybe also marking the existing ones as deprecated.
Update 2025/10/10: as part of the unwinding the great unification (to fix #1745) we considered resurrecting some or all of these packages. The existence of both System.Reactive.Windows.Forms and System.Reactive.For.Windows.Forms is at best confusing. We originally decided we couldn't restore these legacy facades to their original roles because it would create the possibility of circular type forwarder loops if people ended up with certain mismatched version combinations. However, as our plans for how to effect the partial deunification evolved, the assumptions behind that conclusion no longer hold. (We thought System.Reactive would become a legacy facade, and that it would end up with type forwarders pointing to the new home of the UI-framework-specific types. But that's no longer a thing we plan to have happen.) And now it looks like it is possible for at least some of these packages to return to their former roles.
In particular, System.Reactive.Windows.Forms and System.Reactive.WindowsRuntime would no longer be facades, and would return to their original role of being the home of Windows Forms support and Windows Runtime support respectively. We're not so sure about System.Reactive.Windows.Threading. This is a confusingly named package, containing both WPF support and also support for CoreDispatcher. We think the package name refers to a point in history where there were multiple frameworks defining a Dispatcher type in the System.Windows.Threading namespace. (WPF does this, but I think Silverlight did too, and maybe even some older versions of Windows Phone.) So that presumably why the System.Reactive.Windows.Threading package wasn't simply called System.Reactive.Wpf. The fact that it also ended up containing CoreDispatcher support is odd, because that lives in a completely different namespace, but our best guess is that the CoreDispatcher support looks almost identical to the Dispatcher support, and so it went into that package because it was clearly a very close relative to other things already in that package. But the effect is a little baffling because CoreDispatcher is a Windows Runtime feature, and all the other support for that lives in System.Reactive.WindowsRuntime. So we're thinking of putting CoreDispatcher in there, leaving System.Reactive.Windows.Threading as a legacy type forwarding facade and introducing a new System.Reactive.Wpf package, which seems like the obvious thing to search for when looking for Rx WPF support, and which would be consistent with the existing System.Reactive.Windows.Forms and System.Reactive.WindowsRuntime package names.