Wayland won't work well on non-Linux systems, and this is intentional. So, for the foreseeable feature, it can't replace X because its developers don't care.
But the Wayland compositor authors will steer their software to run effectively on Linux. If that means it is difficult to port to Windows or Mac (whether because they miss dma-buf, or demand something that the native platform won't provide to non-system process), so be it.
Which is actually an interesting approach; linux native compositors should "steal" that idea and implement it too. It could lead to RemoteApp-alike for Linux.
Waypipe proxies Wayland over SSH etc: https://gitlab.freedesktop.org/mstoeckl/waypipe/
If you just ran a web browser directly on the hardware (or native window system in full screen mode) instead of bothering with non-great X11 or Wayland or Windows or Mac window systems, then you could write great window managers using open standards that ran identically across Linux, Mac, and Windows, plus mobile and VR devices too.
I was one of those people, in 1994.
Most people don't want to spend hours tweaking Enlightenment themes, or keyboard shortcuts for tiled windows.
How so? I run Electron apps all the time. They behave like any other app.
> Most people don't want to spend hours tweaking Enlightenment themes, or keyboard shortcuts for tiled windows.
Most people don't want to run Linux. And I don't want to waste my free time experimenting with a critical desktop component.
BTW, remember those people who actually make Linux work for the rest of us? Many of them do want to do those things. It's how they got to be Linux contributors in the first place.
Oh do I remember, Red-Hat, Mandrake, IBM, Intel, Oracle, Google, Linaro,....
Slackware 2.0 was my first distribution.
I am aware, that is why I specified which compositor I am running. The comment I replied to said (emphasis mine) "*Wayland* won't work well on non-Linux systems" which is clearly false. To put it into another context: only a subset of C programs run on windows, but it would be silly to claim C won't work on windows.
As for the bug report you linked, the response seems quite reasonable:
> We already have Wayland protocols for input emulation. I think libei should add support for those.
Since standardized protocols exist, why should every compositor have to integrate this library instead of the library integrating support for the standardized protocols?
What standardized protocol? Each wayland makes a different choice. That's the problem. And yeah, I guess I can't say this is a sway issue, their choice is reasonable enough. But it highlights how reasonable actions in a broken system like the waylands can cause problems. They're not doing anything "wrong" and neither are the waylands using libei (all the mouse/keyboard sharing programs target libei, maybe in the future some can target whatever sway comes up with). But it does lead to things not working across waylands. Whereas in X things do work no matter what X implementation you use.