X is somewhat of a joke in the Linux world — that is, nearly everybody acknowledges the fact that it’s an old piece of crap that shouldn’t even see the light of day anymore. Its architecture is based on long-deprecated mainframe systems that would communicate over network connections to client machines just to draw windows. Like the TTYs of the UNIX world, this type of system had long ago fallen out of usage (and desperately needs replacement). We all know that a modern X-based system is a pile of weird components held together by a bunch of loose screws that just barely keep from popping off, and we see this in nearly everything. X still sucks for multi-monitor support, fast on-screen action (the amount of screen-tearing is just unfathomable in fast-paced games), troubleshooting issues is ridiculous, and the protocol is just plain bloated.
But X has one thing going for it, at least over Wayland. X is easy to develop for; it has good docs, good libraries, but most of all, it is a single — albeit fragmented — piece of software. The same simply can’t be said about the cluster-fuck that is Wayland. For those unaware of its design, Wayland itself is simply a protocol that describes how clients should communicate with a compositor, pretty much the same as X11. Except for one fatal flaw — the official reference implementation of Weston has to, by the Wayland philosophy, be a full compositor (which includes everything from the server to the window manager in a single package).
Oh, it can’t be that bad, can it? It’s just a nice little example that you can take apart and repackage for some other compositor, yeah? Except it’s not, it’s nothing of the sort: Weston is a big pile of broken features put into a single compositor to show off what Wayland can do. It would essentially be the equivalent of X.Org with Gnome or KDE baked in, right out of the box.
Of course, if that were the case with X.Org it still might be a bit better, cause I’m pretty sure that would still result in there being less dependencies to build with (most of which Xcb and Xlib hide from you, anyways). On the other hand, the basic Wayland libraries do little more than describe the protocol, and leave you having to work with the underlying components all by yourself. Making a compositor for Wayland that runs on any Linux box is nearly as unfeasible as making a kernel that runs on any x86 machine. Why? Simply because Wayland gives you no tools to make your compositor compatible with the vastly diverse setups out there and the various pieces of hardware that make using DRM or evdev difficult.
So here’s how the issue pans out: your choice, as the user, is either to use a big fucking load of crap (Weston) or to find some prone-to-breaking (isn’t this the problem Wayland was meant to solve?) compositor that barely supports your hardware setup or distro, compile the latest version of it (and all its dependencies) from source, and hope that it’s something you even like using.
