> Windows & Mac are already on exclusively Wayland-style compositors

Only in a narrow sense; nearly all of the features one might reasonably consider fundamental parts of Windows/Mac are “out of scope” for Wayland. Wayland relies on layers upon layers of other solutions for things like central registries, interprocess communication, and negotiating hardware access.

From the Wayland perspective, this is all perfectly reasonable. It’s just how software gets made.

From the perspective of someone who isn’t already running a Linux kernel with evdev + KMS + DRM, we aren’t able to even find common language to discuss what being “a compositor” means to Wayland.

All of the features that are considered "out of scope" for Wayland are also out of scope for other OS's compositors, too. So not in a narrow sense at all.

Wayland is one thing, not an X replacement. There is, unfortunately, not a great story/push to standardize all the other parts of X outside of Wayland's scope.

But it's important to recognize those other parts are also very much not handled by the Wayland-equivalent on other OS's, either. Window's DWM doesn't do clipboard management. Android's SurfaceFlinger doesn't do input. MacOS's QuartZ Composer doesn't do global keyboard shortcuts. And from an app perspective, none of those other OS's conflate those random unrelated things in the way X did, either. They aren't part of the same library or technology group. As in, you'll never find clipboard references in CoreGraphics. You use NSPasteboard which talks to the pastboard server, instead. Entirely unrelated & orthogonal to the compositor, as it should be.

Only on Linux is a full desktop environment stack shoehorned into what's supposedly a display manager.

Fair. The point I’m trying to convey - without burdening the reader with too many specifics - is that there isn’t really any problem with Wayland on non-Linux systems per se, but rather fundamental philosophical and design differences that spiral way out into other parts of the operating system and beyond (into hardware).

A question like whether or not IPC and application buses are managed by a supposed display manager is a more complicated decision than it appears on the surface, with lots of questions that need to be asked that feel like you’re challenging the literal meaning of words depending on which contextual paradigm you’re approaching the discussion from.

The net result is Wayland being a reasonable solution to a real problem that still further isolates Linux into a GUI desktop silo. The result is only “cross compatibility” if you consider the “cross” to mean across Linux distributions, which - in fairness - is actually what most people DO seem to mean.

I got your point, but I'm flat out disagreeing with it. Wayland aligns Linux with the philosophical & design differences of other OS's, it doesn't diverge at all.

In the same way that X's unique snowflake design hasn't significantly impacted cross-OS compatibility, why would Wayland make this any harder? If anything Wayland reduces cross-OS complexity as you can finally have a compositor API on Linux like you have on literally every other OS, which greatly reduces the friction for things like embedding video within an app.

But otherwise right now on any cross-OS application the design is going to assume that composition, clipboard, and keyboard shortcuts are all independent systems. Only on X is that not true. X is the unique, unorthodox design in the broader world of "all OSes"