Wayland is a protocol that can be implemented by so called "Wayland compositors", which then can draw graphics to a framebuffer, X11-Window or Wayland-window.
Unlike on X, the rendering is done by the clients on not by the server. Also each client can see less of their environment, which is stated to be a security improvement, and also have basically no control over how they are placed on the display, which I, having experience writing a window manager for X, quite like. Window management on Wayland should in general be nicer for developers and the few working Wayland implementations I have tried are nice. In fact, Weston, the example Wayland compositor, written b the Wayland developers, is by far the smoothest desktop experience I have ever witnessed on any computer and operating system.
Wayland appears to be the perfect replacement for X, which, while still being one of the most advanced methods of drawing to a screen, is showing its age. While writing antares, my window manager, I am constantly annoyed by all kinds of edge cases, spec-additions and extensions and the hell load of different ways clients should interact with the window manager. And just when you believe everything will work now, some random GUI window thinks it is a good idea to try moving itself (looking at you, Firefox), or not correctly responding to EWMH (looking at you again, Firefox), or simply crash, often taking the entire X server down as well. There are three stages of writing software for X. The first stage is filled with curiosity while you are laying out how your program will work and learning the basics of Xlib or XCB. The second stage is filled with a little bit of frustration but lots of fun and enjoyment, because seeing your program actually work and do stuff is seriously cool. The third stage consists of anger and hate, while you are trying to make your program work with other programs for X and solving bugs which are not in your code but in your understanding of all the specifications and atoms and whatnot, which constantly gain additions.
So Wayland is all nice, isn't it? Well, kinda. It is quite cool and I'd love to port antares to Wayland, but there is a problem: Instead of there being one central Wayland compositor with interfaces for external window managers, like in X, basically everyone writes their own compositor. I think this is not a good idea. This means that basically everyone will reinvent the wheel. Also writing a compositor is a project considerably larger than any simple, singular, sane hobbyist can reasonably work on. Unlike on X, you can not simply write a program that handles just the window management, it also needs to be a server to interact with clients as well as doing a ton of other things. There are wrapper libraries, like wlroots or libweston, which are designed to simply writing a compositor, but those only push the problem one instance further. There is one exception: Weston, the example Wayland compositor, does not provide window management or UI itself. Instead it loads so called "shells" to do this. I am tempted to rewrite antares as a Weston shell, but there is almost no documentation for this. Only a few notes as well as three example shells are provided, not enough to really understand what is going on. I asked the mailing list about documentation and was told that it will come in a (near) future update. But I was also told that it is not particularly easy for a Weston shell to draw window decorations. So while I still want to try out writing some window managing program for Wayland, I am unsure how I should approach it. A Weston shell seems to be the easiest way in theory, but the total lack of documentation is sabotaging the project before I even started it. Maybe I will use wlroots, which is quite well documented, but I do not fancy writing a complete compositor. I also do not like the fragmentation and therefore would want to stay close to what the Wayland developers imagined, meaning Weston.
In fact, there are already incompatibilities between compositors: wlroots provided certain APIs in addition to the Wayland protocol to allow programs like status panels to easily interact with the compositor. Programs depending on these APIs will only function correctly in compositors build on wlroots.
It also does not help that only a few people understand what Wayland actually is. In the mainstream Linux discussions, there will often pop-up lines like "Wayland is not ready yet". Someone who says that has no idea of Wayland. If a specific implementation of Wayland, like the compositor of GNOME, does not work, it absolutely does not indicate at all how well Wayland works in general or how well other Wayland compositors work.