> Forwarding after starting program or disconnecting would be entirely possible with X if toolkits supported it.

Sure, in that case you could even switch back-ends and have your toolkit interrupt its connection with X and start talking with GBM/DRM, Wayland, or another X server. However, the required changes would likely be invasive. I get your point though, this is relatively similar to Wayland programs surviving compositor restarts. However, you would need to start tracking all the state that the X server tracks, to replay it later. Not impossible, but quite hard to bottle on existing implementations, I think.

> Fixing these issues would be a million times more useful than redeveloping everything from scratch

That's your opinion. In my opinion, Wayland does a lot of things right; the main one being a specification that everyone can implement. That makes it much easier to start from scratch to implement an innovative feature in a proof-of-concept toy compositor or program. We've seen a lot of these projects, and consolidation takes time. Once proven, features tend to trickle down to general purpose compositors.

I am really satisfied with the tools Wayland has given us, from gamescope to nested compositors, better isolation, better-behaved clients (no more clients that refuse to go fullscreen, etc), a very stable experience with few crashes (compared to misbehaving clients taking down the X server with them), easy multiseat, no more tearing, no more xorg.conf, better client isolation (notably remote apps cannot spy on locally-running apps), pipewire-based screensharing, choose-your-own-compositor-features approach (granted, not for everyone; but those uncomfotable can stick with KDE or GNOME).

The future seems promising, mostly thanks to wlr protocols, especially wlr-layer-shell that should allow running UI elements from a DE on other compatible compositors (I can't wait to use xfce4-panel on sway starting from their next release[1]).

> I also use ssh -X a lot from home to work and performance is sufficient

Personally, I ran into issues with Cadence, even on a LAN: that software uses some X toolkit, and some very long lists (scrollable form-like dialog) took dozen of seconds to display; I also had various font issues, issues with software moving my mouse (I hate this), performance issues with complex drawings. Most of these disappeared when running through Xpra. Not to mention losing my work because of small internet cuts, putting my computer to sleep, or having the ssh connection interrupted somehow (ssh has trouble with roaming, connecting over wireguard helps with that).

> Xpra shows that it could also work over low latency links if you have latency hiding which the X supports but because it is asynchronous but - again - toolkits never bothered

This is getting too technical, I don't think I'm qualified to discuss this. Though don't you mean high latency links? Xpra is basically a local X server that sends data with a protocol similar to VNC. It is quite similar to how Waypipe handles things. I may be wrong on this, but I think RDP may combine the best of both worlds? Dumb "vnc-like" connection by default, and make use of optimized implementations in the toolkits when available.

[1]: https://gitlab.xfce.org/xfce/xfce4-panel/-/merge_requests/10...