You betray your ignorance of wayland

Option 1: Remote rendering *on top of* Wayland. In this scenario clients (applications) don't do rendering themselves, but sends rendering commands to the display server, which render the windows and ask the Wayland compositor to display them. This will ofcourse require changes to the clients, or to the toolkit they use. You can use the standard compositor (e.g. Weston) on the display server, but will need a rendering server and protocol as well. One existing solution is to use xserver and X11, but developing a better protocol is a possible future improvement.

Option 2: Remote composition *below* Wayland. In this scenario clients render the windows themselves and ask the local compositor to display them. The local compositor, however, does not, but instead compress the windows and sends them over the network to the display server, which in turn asks its Wayland compositor to display them. This will work with all Wayland clients without modification. You can use the standard compositor (e.g. Weston) on the display server, but will need a proxy compositor and client to forward the windows over the network. This is not yet implemented in production-ready code (though there are abandoned proof-of-concept code for older Wayland versions), but is expected to be the default once done.

Option 2 is often called VNC-like because you send pre-rendered images over the network, but unlike actual VNC, you will get rootless windows that integrate just as well as remote X11 windows, so a better description would be Xpra-like. For most (but not all) applications option 2 will require more bandwidth than option 1, but option 2 will require less roundtrips and are thus not as sensitive to lag (a.k.a. poor ping times).

User of dial-up connections and users on over-saturated local networks might want to deploy option 1 (i.e. no change from today), but most use cases will be better served by option 2 (i.e. better performance than today).

The existing robust X backends aren't just going to evaporate, the toolkits are already multi-platform and Wayland is just an additional backend.

> So are the advantages of Wayland with X layered on top substantial enough that it is a major improvement over the status quo?

Yes, it takes the hardware handling out of X and leaves it with just the protocol to support existing apps. The hardware handling can be much better done outside of the X framework than within it. X can be much simpler and more robust if it isn't trying to handle the underlying hardware.

> Or do the real advantages of Wayland only come when you eliminate the X layer in-between?

There is probably sufficient advantage even if the only native Wayland client was the X server although in practice toolkits are going to have a direct Wayland option and eliminate the middleman for local display (only).

> Couldn't you just have libXCB or whatever have multiple backends, one a stub for remote operation using the X protocol, and the other an in-process rasterizer for use with Wayland, etc?

I may be talking above my knowledge level but my guess is that X apps and toolkits just aren't architected in a way where that makes any sense. The people who are designing and implementing Wayland are also the ones who designed and maintain X so my guess is that they are aware of the different architectural options and are picking the best ones.