There are plenty of projects that move something in the Linux world.
The problem with systemd and Wayland is that they are not like any other projects which the users may choose depending on how useful they are for their needs.
Wayland and systemd are forced by a few distribution maintainers upon a great number of Linux users, regardless of what those users may want.
Many users may not be directly impacted by these changes, so they may trust that the maintainers know what they are doing.
But there are also many users for which these replacements would require a lot of work so such users would expect a better justification of why systemd or Wayland are an improvement over alternatives. I have seen tons of presentations about systemd or Wayland, but none of them were convincing. There were never any correct comparisons with alternatives to show that systemd or Wayland are better at something.
I agree than it would be very desirable for X11 to be replaced by something better.
But I have never seen any piece of information that would indicate that Wayland is better. On the contrary, almost every detail that I learn about Wayland shows a bad design decision.
For example, before reading the parent article, I was not aware that the Wayland client API is so reliant on callback functions. In my opinion, this is bad because such an API is inefficient, as it leads to a lot of code duplication.
In my opinion, the cases when it is a good choice to use callback functions are very rare. Instead of callback functions, it should have been better to use some kind of event queue, because there is little else that callback functions can do, except inserting the event into a queue, for handling by the main thread.
The only "advantage" of callback functions is that the implementer of the API might have chosen a bad implementation of an event queue, while an API based on callback functions is not yet committed to a particular queue implementation, allowing the user of the API to do the right thing, but possibly with a waste of code in the initial part of all callback functions.
Avoiding the choice of an implementation for the event queue could still be done efficiently if there were a single callback that you could use for all Wayland functions, which would be your own implementation of the queue insertion function. This would be a good API, as there would be no code duplication, while also not forcing an implementation choice. Multiple callback functions make sense on the server side of a protocol, not on the client side of a protocol, because the messages passing through the protocol might be seen as remote procedure calls originating from the client.
