Wayland's Fatal Flaw
I have used Wayland almost exclusively for a while now and I have generally found it to work perfectly. I use niri but I have also used sway and a few other really oddball compositors. One Wayland design decision always struck me as a little strange, though.
In Wayland, the details of displays and input devices and keyboard mappings are left entirely up to the compositor. In good old X.Org, my keyboard mapping had nothing to do with my window manager. If I changed the direction my scroll wheel worked, my window manager would be none the wiser. Not so with niri or any other Wayland compositor. I have to find the specific way that my compositor configures these things and configure them there. If I switch to another compositor, I have to redo all of that lower level configuration.
This shortcoming is also not entirely theoretical. Recently I found myself needing something like the old autorandr tool. Put simply, autorandr would watch for displays changing and could run a shell script to accommodate the change. When I used i3, I used it to switch between 1 monitor and 2 monitor mode. It would redistribute my workspaces and clean everything up for me. I wanted to do the same thing in niri. If I plug in my big 4k display, I want things split up differently than if I am using my relatively tiny laptop screen.
The approach of autorandr worked because the underlying functionality for changing display configs was universal. No matter what window manager I was using, it relied on the standard RandR extension built into X.Org. In Wayland, no such common core exists. There is only the compositor. Since niri has not implemented this sort of functionality, my options are to open a pr, accept that I can't do that, or wait for the niri team to decide they would like to support that functionality.
I was, therefore, delighted to find that the river compositor is working on splitting the window manager from the lower-level concerns of display and input configuration. They propose a river-window-management-v1 protocol which encodes the communication between an independent window manager and compositor. This should allow window manager authors to just support the window managing itself without having to deal with all the lower level details that really don't change between window managers. It is great to see Wayland slowly picking up useful abstractions from X.Org while keeping things much smaller than the behemoth that X.Org became eventually.