Also for all practical purposes with Wayland you also need XWayland, which means that you get X anyway (especially considering that a lot of simple stuff will rely on X functionality). So might as well stick with X itself and get rid of Wayland as it doesn't provide anything of real value.
How do you launch a wayland server and how do you forward "display" (ssh -X or -Y) to launch a remote application ?
I am lacking a proper analogy here, but it isn't because something is old, and most people are accustomed to its quirks, that it is simple... Maybe Apache, PHP, or even IPv6 would be a better comparison? IPv6 is likely a very good analogy here.
Now, Xorg's "security" model is well understood, just like its security issues. xorg.conf itself is a configuration nightmare. You might be able to launch the X server with a simple command line, but that's just hiding complexity behind a command. I can do the same with sway.
Wayland is quite modular itself. You can probably use namespaces to restrict one app's access to the clipboard, if that's not a feature the compositor supports, for instance.
For network "transparency" under wayland, which is an argument X proponents often cling to (it has its merits, but was counterproductive for most apps), it is a matter of serializing the protocol+image data (that's normally sent trough shared memory), and deserializing it at the other end. That's basically what waypipe [0] is doing, trough Unix sockets. So Wayland can be used remotely over anything that supports Unix sockets, thanks to waypipe, that plays the role of a compositor proxy.
A lot more things are possible due to Wayland being properly specified. The first and most important being multiple, interoperable implementations. Just like the TCP or HTTP stack. That is a Good Thing™ in my opinion. Zero-copy is also simpler to achieve, as another example.
I am sorry if I sound condescending about network transparency for instance. But that was pointed out for so long, and it is even written in Wayland's FAQ. The only reason it was that slow to materialize is Wayland's slow adoption. Which might be in part due to people complaining about stuff like network transparency without understanding it, and making themselves impervious to reasoning, while actually undermining efforts to bootstrap the ecosystem.
> How do you launch a wayland server
A compositor that displays stuff that applications send it? Well, you just execute it. Then that compositor decides to merge that stuff together, or pick some of it, and displays it where it wants: waypipe sends it to a socket, traditional wayland compositors can render on a connected screen trough the DRI kernel interface, others such as sway can even pass the rendered data to an X server or wayland compositor.
> thanks to a single environment variable (DISPLAY)
Use WAYLAND_DISPLAY to specify a Unix socket, if supported[1]. I'll admit that I am a bit in a learning phase, so I don't yet understand everything about the various subtleties (I couldn't use that to start an app from one TTY on another).
So, this distro sounds interesting on paper, but I can't really justify this choice of their, and I am probably not going to use it unless their revise their position. Wayland really needs a bit of forced adoption, like IPv6, if we want to have nice things.
[0]: https://gitlab.freedesktop.org/mstoeckl/waypipe
[1]: https://wayland.freedesktop.org/docs/html/ch04.html#sect-Pro...
(Speaking as someone who just switched to Sway two weeks ago.)
In comparison, Windows Vista introduced a perfectly functional compositor with brand new driver model at about the same time and I can't think of any significant functionality it lost in the process, while I can name many significant improvements.
Hardware acceleration for 2D operations (GDI)
You cannot completely remove X anyway, so using Wayland inevitably introduces much compatibility headache. Just sticking with X is the simples and KISS way to get GUI for now.