> Please tone down the rhetoric, I'm not blaming anybody.
I understand that's not your intention, but that's effectively what you're doing.
I'm a former developer who moved into product management a long time ago, and I've seen the syndrome.
"I understand what you want, but we didn't build it that way, so you need to change your expectations" places the onus on the user to change their behaviour, instead of on the developer to build the thing the user actually wants.
> X is still included on those distros as a fallback option in case you have something that doesn't work.
The trouble is, a neophyte will a) have no idea what the difference is between Wayland and Xorg, and b) not realize that switching might fix whatever issue they're encountering.
And BTW, this all presumes that a distro installs Xorg at all. If not, you've gotta dive into the package manager, which adds an additional barrier since you need to know what to look for and install.
> Re global hotkey bindings: Can you please describe your setup to me? I honestly have no idea what you're talking about, global hotkeys were supported in all the Wayland implementations I tried recently. (KDE, GNOME, Sway, Wayfire)
It certainly doesn't.
Two examples that immediately spring to mind:
Guake, a handy pop-up terminal. In X I can press F12 anywhere and it opens. Super handy for quick terminal interactions, always-on commandline tools, etc.
Gnome Do or equivalent. Basically Quicksilver for Linux. Fast search, command execution, etc, from the keyboard. Hit a hotkey and it pops up.
Right now the way this works is that the compositor binds the key and then... does stuff. But that requires these applications to be redesigned to support that. For example, guake added a whole separate binary, 'guake-toggle', and it's only job is to toggle visibility.
Unfortunately, that requires the user to know that they need to go into their compositor settings, bind the key, and set it to run that application.
Meanwhile, on literally any other OS, this would be handled with a config setting right in the application.
Maybe eventually be addressed with yet-another-dbus-protocol, but right now it's just a gaping functional regression.