Very naive question, but what is the difference between this and XWayland?
An X server is a display server: it can run on its own, and apps can output to it, with nothing else running. When one program runs early on and provides windows furniture, that's a window manager.
If that program (or associated ones with a uniform look and feel) also provides UI functionality so you don't need to use a command prompt, such as tools to launch apps, see and manage files, edit text files, mount and unmount media, and maybe things like see the time, adjust system settings, do calculations, etc. then that is called a desktop environment.
Wayland is not like this. Wayland is a protocol. There are no separate display servers. What under X is called a "window manager" usually talks Wayland and so other apps talk directly to the WM over Wayland in order to display stuff.
There's no bottom layer program, no server. The WM is the display server. Without a WM you can't run anything.
That means you need a Wayland compositor to run anything else, such as XWayland.
This means that you can't use an X WM to be the compositor, because the layer needed to run the WM is not there until another different app provides the Wayland environment, and then it's the WM and your X WM can't take over. Remove the compositor, there's no GUI.
This is not a question of whipping out the tablecloth from under a fully-laid table. It's removing the table.
So what this project looks like is a compositor that isn't a WM and so enables Xwayland to run full-screen as the root window, letting you use an X WM as your desktop with no Wayland WM.
It sounds of great interest to me because whereas there are about half a dozen X desktops and environments I like, some I've been using for decades now, there is not a single Wayland environment I would be willing to use.
That's not to say there's some non technical decisions which are making porting a lot harder *cough cough* mouse warping *cough cough*
You should use Wayland because it's what's supported. It's what all future Linux graphical software will be ported to. In a few years, it'll be impossible to get an X version of even a recent web browser. The best time to abandon X was 30 years ago. The second best time is now.
This is a similar situation to the people who were all screaming that you had to ditch Python 2 to upgrade to Python 3 immediately after it came out, and that if you didn't you were somehow dumb, even though they finally started to fix all of the upgrade deficiencies and regressions only with something around Python 3.5: there's a time to upgrade, and that time is never immediately upon introduction.
What people do not seem to get is that Wayland is what they wanted Xorg to be. A lot of what Wayland could not do were things they did not think it should do.
In some cases, the Wayland team has been dragged kicking to implement things. In other cases, they have stood firm and we will be leaving them behind.
You also still don't get an easy solution to much of what users actually tend to complain about -- which are the lower level components and driver support that Xorg had that wasn't matched by Wayland until recently. There's a whole entire stack of low level stuff developed over decades that made "just install linux" possible on so many PCs. The higher level components that something like XWayland or Xephyr implements is only a miniscule fraction of the Xorg codebase, that has largely remained the same since the 1980s (but is surprisingly easy to maintain on its own).
Many things on X are done the way they are because all processes can see all pixels and all devices. Wayland does not want that. So, tools built to these requirements will not work. And, obviously, they cannot be “fixed”.
IMO, this is Wayland's original sin.
The "Display Server" part of things is tens of thousands of lines of dealing with obtuse hardware and protocol technicalities. It needs to be fast, reliable, secure, and up to date, but otherwise is very much anonymous infrastructure.
The "Compositor/Window Manager" part of things is relatively small and likely to be much more opinionated on what features and behaviour it offered.
In the X11 days, a Window Manager could be simple enough to fit in a chapter of a book (the O'reilly X11 books had one IIRC). For Wayland, because they're under one hood, to get to the same place, you're looking at a huge, ongoing development effort, even if that consists of importing something like wlroots and building on top. That's enough to severely crimp the array of choices available.
People are being told they have to give up their X11 workflows and configurations, and the replacements are often lacking in some dimension (less functional, difficult to configure the same way, more resource intensive) Nobody should be surprised there was hostility and pushback!
Maybe the way to go would have been instead of building the ugliest possible Windows Vista On An Old Pentium 4 That Doesn't Qualify For Aero Glass look on Weston, they should have focused on building a "shim compositor" library that was specifically designed to ease porting X11 window managers, by providing APIs that looked similar to existing X11 ones.