One begins to understand the advantages of this approach after 10-15 years or so.

I feel that I am constantly being forced into new "UI paradigms", and it isn't always a change for the better. I started with DOS (Norton Commander, anyone? to this day there is no comparable tool), then Windows 3.0 and 3.1 (which was mostly garbage and I did not enjoy the UI at all). I then started using Linux and discovered Emacs. When I could afford the extra megabytes of memory, I would also run X11. As years went by, I switched to the Mac.

These days I'm worried about what will be taken away from me, especially with Apple and their insistence on removing ports, the idiotic "Touch Bar" instead of function keys — but also with Linux, where the shift away from X11 means no more remote applications, and the (increasingly broken) approach of gluing everything together into a big mudball means that if you're running anything that isn't "mainstream", things break and you are very much on your own.

But I still have Emacs and I'm fairly confident that it will remain available and running on every platform I decide to switch to. And that I will be able to run it (with reduced functionality) on a text terminal.

The shift away from X11 means no more forwarding X11 applications over ssh, which is slow at best and buggy and insecure at worst. A small price to pay for eliminating tearing and actually-secure screen locking. There are valid criticisms of the move to Wayland but I don’t really think this is one of them; if you really need remote access to graphical applications you almost certainly should not be using X forwarding.

> The shift away from X11 means no more forwarding X11 applications over ssh, which is slow at best and buggy and insecure at worst.

Yes but sometimes you really need that and it's a life saver.

EDIT: I just remembered about LTSP (Linux Terminal Server Project) which many schools used to lower the TCO of computing infrastructure. That relied heavily on Xorg's network transparency. I wonder what will happen to LTSP

Honestly, I think people's reliance on X forwarding is just due to the fact that it happens to exist, not because they really need it. There's nothing like X forwarding on Windows to my knowledge. If X forwarding didn't exist people would have figured out how to do what they needed over SSH with text or when GUI's are irreplaceable sysadmins would have set up an actual remote desktop solution like on other modern operating systems.

The happens to exist bit turns out to be very important. I can login to a machine and run an X client without installing and configuring extra software on the server. If I am using a desktop with X installed (most *ix based systems), there is no extra software to install and configure on that end either. The worse case scenario is the necessity to install an X server on platforms like macOS and Windows.

The same sort of thing can be said for Remote Desktop. If you're using a version of Windows that includes it, it is wonderful to use because it is just there.

Which is better? It depends on how you're using it. I generally prefer Remote Desktop for my use case because it takes care of audio and it is easy to resume sessions. That being said, those features don't matter to me most of the time so X is just as useful.

Right, the shift away from X doesn't mean the death of using GUI apps remotely, it just means moving to a Remote Desktop model instead of telling apps that their render target is your X server through a tunnel.

What implementation of a remote desktop model currently exists for Wayland?

The "big two" have implementations. Definitely not mature but it's getting there.

https://wiki.gnome.org/Projects/Mutter/RemoteDesktop

https://docs.kde.org/trunk5/en/kdenetwork/krfb/krfb-configur...

You most likely won't see an implementation "for Wayland" because that's like asking for a websocket implementation "for HTTP" the actual compositors that speak Wayland need to implement remote desktop capabilities and then expose an API for managing remote desktop sessions (org.freedesktop.portal.RemoteDesktop) to programs that want to leverage it.