Wayland is one of the greatest software disasters in history. There are still some people in denial, but in another 10-20 years, virtually everyone will look back on Wayland with embarrassment wondering how this could have happened. This project has probably held back linux userspace graphics by at least 10 years. Wayland is basically sold as a "lean", "modern" replacement for Xorg without Xorg's technical baggage and a protocol that makes the "right" decisions. The hilarious thing about this is that Wayland's technical core is completely wrong and full of bad decisions. It's not some coincidence that it's taken so long for the thing to even be slightly usable.

>rendering model
Wayland's rendering model is completely broken. How it currently works is that compositors throttle rendering by not sending callbacks to surface that are out of focus. The throttling can indefinitely stall that application's thread until it comes back into view. The problem is that clients have no way of knowing if they hidden or not. What ends up often happening is that certain render loops do clever hacks/workarounds to guess when the surface is hidden or not to avoid this stalling. There was a protocol proposal to fix this, but it got bikeshedded and probably will never be merged. Note that Wayland is literally the only windowing protocol that works like this and everywhere else it's trivial. What Wayland should have done was just send visibility events instead of callbacks and then encourage applications to not draw when the surface is not visible.

>scaling model
Time has proven Wayland's scaling model to be completely wrong. It took 14 years, but upstream is basically admitting this by working on the fractional scale proposal. Restricting the core protocol to only interger scaling is clear madness and in today's world of HIDPI, it's an embarrassing relic. Fractional scaling in compositors currently work by tricking clients to render above the display's resolution and the compositor downscales it after the fact. It's one of the dumbest possible things someone could have come up with. How this should have worked is that applications just mark themselves as "DPI aware" in some way to stop all compositor-side scaling. After that, the compositor just passes some value (could be DPI, a fixed number, whatever) that the application than uses to scale itself properly. Non dpi-aware applications can just be upscaled by the compositor when needed.

>security model
Wayland's security model is another thing they completely messed up. Having more security is nice and all, but you have to make sure it doesn't hurt usability. Unfortunately, Wayland went to the extreme of having security to the point where push to talk can't work (yes really). Wayland advocates will point out that Xorg allows "keylogging" since programs can see key events, but this is a neccesary and useful part of any windowing system. You can see key events in Windows and macOS too. Nobody seriously considers it a "security issue". Providing a way lock it down is sensible, but the default should have been just the same as other OSes and Xorg. The obsession with security is also what lead to embarrassing situations like screen recording not working until pipewire fixed it by using dbus. Decisions like this make writing automation type software that sends key/mouse events pretty much impossible with Wayland. Eventually, people are just going to use evdev and bypass this altogether which negates all this supposed security.

>synchronization model
This one is a bit more obscure, but Wayland's synchronization is outdated as well. In fairness, they started in 2008 so this wasn't clear then, but modern graphics developers all agree that explict synchronization (like Vulkan or Direct3D 12) is the correct way to go. Wayland and Xorg are both implicitly synchronized which essentially means that they depend on APIs executing in a specific certain order (e.g. in Wayland a client renders, sends a surface commit, then after that the compositor does its thing). This scales poorly as clients become more complicated with rendering and leads to a ton of over-synchronization. The correct fix is to use explict synchronization. All the commands are executed as asynchronously as possible with synchronization only happening when strictly necessary. The kernel graphics substack is still playing catch up on this as well, but Android moved SurfaceFlinger to explict synchronization a couple of years ago. Xorg's present extension allows waiting on a CPU fence which is OK but hardly there. For Wayland, is an explicit synchronization protocol that nobody on the Linux desktop actually uses (it's for ChromeOS when it interfaces with Android applications under Wayland) which has some limited support. A correct windowing system needs to be designed from the ground up to support this. Basically like what Android did.

Points 1 and 3 will never be fixed (note that Xorg doesn't have either of these problems) since they go against the Wayland philosophy. Point 2 might eventually be fixed (note that all Xorg is missing is a nice, DPI-per-monitor type field.). Point 4 is not even on anyone's map because everyone is too busy fixing more basic Wayland issues. Basically, Wayland was built from the ground up on incorrect technical decisions and is still busy playing catchup with Xorg on several points. Note I haven't even touched on some other failure points like everyone reinventing the wheel constantly in wayland. Hypothetically continuing to improve Xorg or instead starting a new, actually good protocol (one that didn't have all the design flaws of Wayland) would have been far better. Right now, the reality is that userspace graphics on desktop Linux is behind Windows and even Android now. macOS is full of broken shit, so we can at least cope there somewhat but it's just not a good situation. Wayland was truly a mistake.