That's because what seemed like the best way to do hidpi when macOS added it (fixed scale factors and assets) ended up being a problem. It's better to not abstract away the DPI differences. It makes for worse compatibility in the short term, but much better long-term.
The behavior with high refresh rates is pretty bad, too. A lot of stuff is hardcoded to 60hz, and programs have to opt in. They haven't even fixed Safari properly yet.
Every time I read about the benefits of Wayland, I read shopping list of stuff I don't care about and don't want. I don't give a stuff about techie nerdwank like refresh rates, tearing, video smoothness, triple buffering and other pointless implementation details that it is the entire job of a GUI to make go away.
What I care about is that I plug in a screen, I drag a window onto it, and it stays the same size. That my window can straddle two screens and still work. That I can resize it across as many screens as I want.
I want it to work and I want how that happens to be invisible.
Wayland, as far as I can tell, is about xNix graphics programmers complaining about how hard the job is, I'm afraid.
From what you describe we actually strongly agree. This stuff should work and be invisible to the user. I just meant that the environment should expose the DPI details to the programmer and not pretend everything is low dpi like it's always been.
Wayland is about a bunch of amateur programmers learning for the first time how graphics work, individually and separately all in parallel. Wayland needed to have a bigger, definitive core library designed by experienced developers. What we've got now instead is a myriad of low-level graphics implementations, none of which handle edge cases very well.
