Anyway I'll get into it. From my perspective from actually working on this, the problem with most of these statements is that none of these things can actually be fixed in Wayland. Wayland is just a really basic protocol for putting buffers on the screen, it doesn't do much else and it's intentionally not good at being a general purpose API for desktop-y things. Your article seems to assume that it is, which is a misconception, and only causes confusion. If you actually tried to fix these problems by making changes in Wayland then you would make the problem worse. Most of what is mentioned absolutely are problems, but they need to be fixed elsewhere, and the claim should probably be rephrased to reflect that if you want it to be accurate. To be clear, I am in no way trying to downplay any of these problems.

"Wayland doesn't provide multiple APIs for various crucial desktop features"

So some of these are in the portal API, not wayland. It doesn't really make sense to put them in Wayland, some implementations do provide them in Wayland but that's more of an implementation detail and applications wouldn't actually be expected to use that API. Some of them are still missing from the portal API however, which is a problem, so maybe this should be edited down to just those. I'll talk about each of them too.

- global keyboard shortcuts - It's not clear what this means. There were some proposals for this but none adequately explained the problem.

- drag-n-drop - Not sure what else you're looking for here, Wayland has this.

- systray - There are implementations of this, it doesn't belong in the wayland protocol. It would be for a panel to communicate with an app.

- screenshotting, screencasting - This is in the portal API.

- UI rendering acceleration - Not sure what this means, Wayland clients can just use OpenGL or Vulkan.

"which must be implemented by the window manager/compositor, which means multiple applications using the said features can only support their own Wayland compositor implementations"

I'm not sure what this means, applications can use an abstraction layer that deals with it for them. Most applications already are using such an abstraction layer like GTK/Qt/SDL/etc, they should not have to deal with the raw X11/Wayland API.

"Wayland doesn't provide a universal basic window compositor"

This is not the use case of Wayland and it would not be possible for Wayland to provide this. You could build such a compositor on top of Wayland.

"thus each desktop environment has to reinvent the wheel and some environments simply don't have enough manpower to write a compositor e.g. XFCE/IceWM. This also leads to a huge amount of duplication of work (and bugs as well) because various desktop environments need to reimplemen the same features and APIs over and over again."

Well no, if they're short on manpower they can just use an existing compositor such as Mir, wlroots, mutter, etc. The real problem here is that they are short on manpower, nothing can be done in Wayland or X11 or anything to really fix that.

"Wayland and its window managers/compositors have very high requirements in terms of support from both hardware and kernel drivers which prevents it from working on far too many configurations. X.org and Windows on the other hand can work on an actual rock using e.g. VESA."

So this is an actual problem but it's not really related to Wayland, e.g. if you want to run an X compositor on an old PC that will also have bad performance because it requires hardware acceleration. And if an app itself requires Vulkan or something then that definitely won't work. I'm not sure what can be done about this and this seems like complaining about an unsolveable problem, you will also have similar problems if you try to install Windows 11 or MacOS Monterey on an old PC and try to run modern apps on it.

"Applications (or GUI toolkits) must implement their own font antialiasing"

This is completely wrong, basically all applications and UI toolkits just use freetype.

"there's no API for setting system-wide font rendering"

This is also completely wrong, this is what fontconfig is for. It's not the best API though so this section could be rephrased as a review of freetype and fontconfig.

"Most sane and advanced windowing systems work exactly this way - Windows, Android, Mac OS X."

This is also completely wrong, I just checked Android and MacOS and there is no setting to change the font rendering. Not sure about Windows as I don't use it.

"Wayland does not provide a basic universal unified graphical toolkit/API (and Wayland developers will not implement it)"

See what I said above, Wayland cannot implement this. If you wanted this you would have to build it on top of Wayland. Wayland is a API to use when implementing a toolkit.

"akin to Win32 which means applications using different toolkits (e.g. Qt, GTK, Enlightenment) may look and behave differently and there's no way to configure all of them once and for all."

Toolkit fragmentation is a real thing which should be mentioned in this article, but see above again, this is not something that Wayland is ever going to be in any position to fix.

"Firstly, forget about performance/bandwidth efficient RDP protocol (it's already implemented but it works by sending the updates of large chunks of the screen, i.e. a lot like old highly inefficient VNC)"

Another thing that Wayland is not in the position to fix. This would be nice to have but would be up to the toolkits to implement.

"forget about OpenGL pass-through, forget about raw compressed video pass-through"

This has to be implemented in the VM host, there is nothing a Wayland implementation can really do about it. The Wayland protocol only receives the dmabufs and YUV buffers and passes them off, it doesn't say anything about what to do with them.

"In case you're interested all these features work in Microsoft's RDP."

Yeah so that would be a problem with the RDP implementation, FreeDRP or whatever.

"Secondly, forget about proper output rotation/scaling/ratio change."

That thread is really confusing and nonsensical to me. If you have non square pixels then you just make the application aware of the vertical/horizontal DPI in some way. Wayland doesn't even need to get involved, it will just display your buffer as you pass it. Wayland itself doesn't assign any unit to a pixel.

"Wayland doesn't allow XWayland applications to change display resolution which could make running games slower as the compositor needs to upscale each game frame."

This is more of a problem with X11 since there is no "safe" API to change the display resolution there. Maybe someone could fix it but those apps really need to be ported to a different API.

"Also software upscaling might not be the best option."

Well most compositors are using hardware upscaling.

"Wayland doesn't allow applications to exclusively grab mouse/keyboard which is required for games and applications like VMs."

This is wrong, that's what the pointer constraints protocol is for.

"Applies to the X server/protocol as well: neither X.org, nor Wayland window managers offer a way to extend/modify window's title bars and File Open/Save dialogs."

This again has nothing to do with X.org or Wayland. The title bars and file dialogs are handled by the toolkit.

"there's no unified toolkit and no unified window manager (or protocol)."

So I think you could just replace this entire section with this statement and then go from there.

"Wayland compositors don't have a universal method of storing and configuring screen/session/keyboard/mouse settings."

This one's potentially a real problem, but again, it's not clear what "screen/session/keyboard/mouse settings" are. That could be thousands of things. And this also has nothing to do with Wayland because it's not a protocol for configuring settings.

"Currently there's no standard way to remap keys under Wayland."

See above, this has nothing to do with Wayland.

"Wayland applications cannot run without a Wayland compositor and in case it crashes, all the running apps die."

This statement is badly worded, technically this isn't true and it just needs to be implemented. Which is the real problem and is currently underway, see here: https://lists.freedesktop.org/archives/wayland-devel/2021-Au...

"An assortment of various other general and KDE specific issues."

These are valid issues, please make these issues more prominent.