"Wayland" works fine, but as soon as you start mixing X11 and Wayland apps, it starts getting complicated due to different levels of functionality support for the two APIs.

I started running into them pretty fast when I added a 4K monitor to my Ubuntu 22.04 system and enabled fractional scaling. All of my Wayland apps look fine, and all of my XWayland clients look awful, blurry and obviously scaled. Working one by one to switch them over to native Wayland has been a hassle for various random reasons, most notably:

* Slack: works from the icon in the taskbar, but when auto-started at login does so in X11 mode

* VS Code: works fine when run from Terminal, but when launched from taskbar icon shows up as a different "app" in the taskbar. Launching from the terminal starts in X11 mode

* Zoom: requires more setup in order to share screen. The Zoom UI for screen sharing doesn't work so it's not obvious how to stop sharing screen. It also freezes or crashes all the time for no discernable reason, including locking up when joining some meetings three times in a row and then succeeding on the fourth time.

So if you're not really leaning into what Wayland offers it works fine, but even just fractional scaling has been a four-month hassle to get things working as expected.

I've been using fractional scaling and only native Wayland apps since May 2021 (on Fedora) though I don't use Slack, VS Code or Zoom.

As you know, "native Wayland" means the app has been modified so that it can talk to the graphics hardware using the Wayland protocol.

Emacs is the hardest of my apps to persuade to talk Wayland protocol because Fedora's "emacs" package was compiled without the code that talks Wayland.

To persuade Chrome to talk Wayland protocol, I start it with specific command-line arguments, which used to cause bugs, but I haven't noticed any bugs for months.