People over-emphasize a lot of the problems X has. A lot of the real original problems like high latency were evolved away. And while backwards compatibility ca

People over-emphasize a lot of the problems X has. A lot of the real original problems like high latency were evolved away. And while backwards compatibility can be annoying, that's just what you get for trying to do serious software engineering. So I agree with you that the differences between X and Wayland are greatly exaggerated. However, there is one significant architectural difference between X and Wayland that is quite difficult to evolve away. In modern X, there are actually three processes involved: the client (app), the X server, and the compositor. In Wayland, there are only two: the client (app) and the compositor. The X design is more fragile (state managed in 3 places instead of 2) hence ICCCM, and has more latency and overhead. However, it made a lot of sense back when the X server talked to the hardware directly and therefore needed both an integrated driver and special privileges. It'd be silly to implement drivers as part of compositors, so the separation of mechanism and policy was the right way to go back then. Since then, however, the mechanism has basically entirely moved into the kernel (DRM/KMS) and Mesa (OpenGL). This happened in bits and pieces first with the evolution of the DRI protocol and then the jump to kernel mode setting. That is the evolutionary development which lead to the move to Wayland makeing sense. I suppose this 3-to-2-process transition could have been evolved by refactoring the core of the X server source (the whole protocol handling etc.) into a library that compositors then simply link against. But that would have been a truly herculean task with not very many natural intermediate steps. Implementing something like Wayland from scratch on the modern Linux graphics stack is actually much less work -- except perhaps for transitioning all the toolkits, but then again, the X server source lends itself fairly well to writing various "X-on-something-else" servers, since people have been doing that for a while, so there's a natural if slightly awkward solution for backwards compatibility. So hacking up an initial prototype for Wayland could be done very quickly, but note that actual adoption still took a long time. But the point is that the Wayland path had more presentable intermediate steps (unlike the X server refactor), so that's the path that software evolution took. (Man, this got a lot longer than originally intended...)