Someone could build a combined Wayland/X server in the same process like that, but why? The only reason you would need to do that would be to run Wayland clients natively on your X server. IMO if you want to use Wayland it is much easier and more valuable to just port those tools. The hotkey daemons, screenshot tools, and command-line clients are pretty small and not that hard for someone to rewrite as a weekend project, people have done a lot of that already. The harder part is the window managers, but if you're a hard-core window manager author used to doing things the X way then you won't see much reason to switch anyway.
If the Wayland/fd.o crowd insists on breaking things I relied on to the point where I have to work weekends to fix everything that used to work, I'm going to spend that time replacing whatever software they wrote that I use with software that I wrote, since at least I won't be breaking my workflow.
I don't understand what you mean. You can still continue using X if that's what you want, people deciding to spend their time developing Wayland doesn't somehow break X or make it worse.
Also just FYI, it seems x.org has merged with freedesktop.org so they are mostly equivalent at this point, being run by the same group of people.
I'm assuming that X.org will go unmaintained after a time, which is fine. But if that means I can't get a usable X server running later on, I wouldn't mind taking a crack at adding a Wayland extension that implemented the X11 protocol.
It's not clear what that would solve, XWayland mostly fulfills that role already. It can't run window managers, but you wouldn't really get that everywhere from adding another Wayland extension either -- doing that would require a lot of additional code and the GNOME and KDE implementations wouldn't want that anyway because they have their own built in window managers. So maybe you could get a hacked up version of Weston that can run X window managers, but why bother dealing with maintaining that instead of just maintaining X? It's unlikely the X server will stop working as long as you have a GPU that supports GL or Vulkan, the glamor/modesetting driver should continue to work there.
In the event that I do need to use something that is Wayland-only, I'd like to have the ability to run it without breaking everything else.
I mean, X.org runs well enough on my end? I'm not finding myself wanting something with lower input latency.
> The difference is that the X compositor is just storing a copy of large amounts of state from the X server, whereas the Wayland compositor would store the canonical data and wouldn't need to worry about falling out of sync with the X server.
Honestly, if I were to do a ground-up X11 implementation, I'd probably build it around wlroots or similar. Then Wayland clients could interact with it, and I'd be able to preserve all the X11 compatibility and X11-isms I cared about. Like having separate window managers, hotkey daemons, screenshot tools, the slew of X11 command-line clients I know and love today, and so on.