> Using xkb options results in some strange behavior. Also, hotkeys involving alt-shift are sometimes garbled (i.e. you press alt-shift-k and it results in switching keyboard layout and printing 'л').
Well, you switched layout and pressed some key... Anyway, that's not X11 problem, just a bug in xkb in worst case. And it's not solved by Wayland (you probably don't know but Wayland/Weston kind of uses xkb :)). But if that's a bug it should be fixed. Just curious, what is expected behavior for you?
> So it's impossible even when I'm pointing to you that it IS already done? And using a Wayland protocol extension.
What you linked is same as what you have with Xorg, and don't like so much. :) And that's a compositor extension (suggested, since it's not a part of weston), it's not part of Wayland protocol. Wayland compositor is like HelloWorld program, you can extend it to do everything you want. But it will be supported by that compositor only.
It is one of the greatest problem of the entire Wayland design — it encourages you to put every missing feature into unique compositor extension, so you eventually end up with lots of incompatible compositors, each having a small subset of all the Xorg abilities and standards.
> Virtual desktops on Mac OS X are the same thing as virtual desktops on X. And Mac OS X allows virtdesktops on a same display to have different resolutions (which X doesn't allow, btw).
Virtual desktops on X are up to the window manager. Nothing stops it from switching resolution when you switch desktop. So again, that's not X11 problem.
> I don't care about many options. I want a display stack that works consistently and predictably in most cases.
Then what stops you from configuring it the way you want? X allows you to do that, Wayland/Weston does not.
> Wayland is so great because is designed from the start to BE RELIABLE in the modern world.
It's not designed to "be reliable". :) Sorry. It basically designed to be "like X but better". On the other hand X is reliable, because it allows you to configure it the way you want, and it will work that way for years.
> For example, X still has problem with subpixel rendering
> because there's no way for the client-side library to know the current display's orientation. That's why KDE and GNOME have separate manual settings for them, while Wayland carries this information in the native protocol.
So does X. Check `xrandr --verbose`. (Oops) :) KDE and GNOME just allow you to configure some Xft/fontconfig options manually, because many (most?) monitors actually do not provide that information. And because some people don't like subpixel font hinting. Would you prefer it to be unconfigurable?
> Then there's a whole question of synchronization. Wayland devs spent quite a lot of time discussing the whole double buffering mechanism, making it much more robust than in X (where buffer swap either stalls your pipeline or can happen at indeterminate time).
(You talk about that as if you never used Wayland/Weston and never seen how windows blinked like crazy when you resized them) It's not that I understand what problem you talk about but who cares? Yes, Wayland is a lot about "we don't like how X does that so we do that differently", but who cares? Nobody works on that low level. And those who do (authors of toolkits and compositing managers) have already implemented that ten years ago. What's the point in changing the protocol that people either don't care or got already implemented and working?