> Two things: First, yes, a lot of Wayland's missing features absolutely were intentional omissions in the name of security. This is even almost understandable; the only difference between a vital a11y tool and horrible malware is whether the software acts on behalf of the user or against them, there is no technical distinction. Second... Wayland is almost 17 years old. If it was 2010, I would readily accept that it was early WIP software, but we're past the point where 'they just haven't gotten there yet' is convincing.
Firstly, the problem is when you put it this way, people think that Wayland can't do accessibility, or screen capture, or automation. It is true that it is intentional that a Wayland program can't simply expect there to just be the ability to go and read screen contents (or inject inputs, or intercept input, or ...) without permission, but that's not just security, I think that's also somewhat a result of the fact that the Wayland core protocol is really not applicable to any specific use cases, and is really just the bare bones necessary for programs to talk to a compositing system. For example, you can't really do proper desktop applications as we know them without something like xdg-shell, which isn't part of the core Wayland protocols, and yet it's totally possible to have Wayland protocols that do things like screen capture, and they can be as "standard" as the ecosystem wants. (Unfortunately that stuff usually gets relegated to DBus presumably because nobody actually wants to support authorization on the Wayland side, but oh well.) To put it more clearly, there is absolutely no reason that Wayland desktop systems can't just expose every bit of functionality X.org allowed to all apps if they want to, security be damned, and the protocols can be standardized; wlroots compositors usually do basically this after all, and I think these days the protocols are all ext protocols upstreamed to wayland-protocols. (And in practice, secure alternatives that allow for proper automation/accessiblity/etc. are very likely to exist and be supported by all major desktops in the long run.) I think people get the wrong idea that Wayland is telling them they can't ever do this, but it's really just telling application developers they can't absolutely count on being able to do it like they can in X.org.
Secondly, the "Wayland is x years old" thing just doesn't make sense, this has to stop. This isn't a project with full time employees like at your job, it's a distributed open source effort. The investments are incredibly uneven both over time and for specific areas of interest. Until about 10 years ago, Wayland was basically not usable at all for almost anybody, and until the last few years the vast majority of Linux users were using NVIDIA GPUs and couldn't really use Wayland without pretty terrible bugs (XWayland was especially broken. AFAIK to this day NVIDIA is working through XWayland issues that never existed on AMD/Intel.) The momentum Wayland had back when nobody could really use it was pretty damn bad. This isn't really terribly unusual for open source projects of this nature though; I mean look at how catastrophically long it took for GIMP 3.0 to come out, and that is a lot less complex and multifaceted than entire desktop systems.
I'm not saying that the initial work done on Wayland was bad or not important, but the majority of work done on making Wayland usable in real life happened in the past few years. 17 years ago or so, all that existed of Wayland in practice were some ideas about how to design a graphical interface system to succeed X.org. (and at that time, Wayland's design was probably too radical anyways: I don't think it's clear that all Linux users would've accepted things about Wayland that hardly anyone complains about today, like the pervasive use of compositing without a traditional fallback. Today X.org is basically the only commonly used windowing system that can properly operate without some form of compositing.)