Weston is the older and original compositor for Wayland. And I read that it's a mess. This might be the only compositor compatible with both libx and libxcb through Xwayland. I think Weston would be a stepping stone and good testing ground, similar to what
Beastie7 wrote. Weston is the only compositor which can be tested for Xwayland for both libxcb and libx applications right now.
While, it's a good thought about Weston, I don't think that's the longterm answer, because I read that it's not well organized and not built as well as WLroots. WLroots got to learn lessons from Weston. So, whatever compositor will be, it needs to learn lessons from both of these compositors.
WLroots might only be compatible with libxcb and not libx through Xwayland. There's very few programs in libxcb, and some have parts or dependencies still in libx. So, WLroots could be tested right now for pure libxcb progams, through Xwayland. For reference, WLC is defunct which was replaced by WLroots.
I based possible compatibility with libx or libxcb from looking at WLroots and Weston's documentation for what it had dependencies for or what it had parts of for use with Xwayland being libx and/or libxcb.
Wayland can work for everyone. It's modular for use. I see it for using an updated Xwayland or other compatibility layer for libx and libxcb built applications. Why not have the better Wayland protocol replace X, so existing programs can run on that as is. It already shares the same drivers from Xorg. Not all compositors are compatible with Xwayland, libx or libxcb.
The compositor and components would be for a compatibility layer, so existing X11 (both libx and libxcb) applications which don't have a graphical toolkit can run natively on Wayland.
As long as the vast catalog of programs is largely under libx, we'll need Xwayland or an implementation for libx for immediate use. Hopefully it transfers to libxcb over time, so libx can eventually become defunct.
We should adopt a BSD compositor, and make a better Xwayland layer, along with making it compatible with libxcb and libx. So that everything works. In the meantime, it can wean off of libx to libxcb, for likely a period of 10 years. The whole time, let those run alongside programs which use the toolkits of qt, gtk and SDL. There's no reason to not have more toolkits.
I think we should take Weston and steward development of it towards a reference compositor like Xorg IMO. First party support for FreeBSD is already there, and It'll be easier to add in our own FreeBSD specific improvements too.
I agree, except it shouldn't be Weston, because it's the primitive version of a compositor. Weston needs to be that for testing now, but it needs to be a better compositor. Perhaps a cleaner one based on both Weston and WLroots.
In short, Weston is a current testbed for that, rather than the long-term compositor which may not exist yet to steward. If Weston were to be stewarded, it would be great to be stewarded only as a testbed, and getting X11 applications to run on it might be possible in less than a month on it. Weston can remain as a long term testbed.
Wayland doesn't have to be looked at so negatively, because the compositor can be whatever type of compatibility layer or whatever else you want it to be, while being able to use the improvements of Wayland. Whichever compositors chosen, stewarded, or used, can leave out un-useful overly complicated Linuxisms, as they would be modular that way.