This does not allow one to write a screenshot application; this has a protocol that allows Flatpak applications to requæst that the compositor take one and as far as I know it only has support to take on from the entire screen.
Most compositors also have the ability to take such screenshots outside of Flatpak; this simply moves it inside of it.
The “screenshot issue” with Wayland is not that compositors can't take one; it's the lack of an the a.p.i.'s necessary to write software that can take one.
> For generating fake inputs, a library is being worked on called libei, that also should work in X11, Wayland, and within a sandbox.
I could find nothing on this on the internet.
> For controlling monitor outputs and open windows, those APIs are different because each compositor has a different set of features for what those mean. Generally you should not be using random applications to configure monitor outputs, only your compositor's configuration tool is going to be reliable there. Applications that need to set custom resolutions can use the viewporter or use fullscreen-shell.
And that one “should not do this” yet this is supported and used by many on X11 would be one of the missing features that would lead to Wine developers not being interested in a Wayland port.
> Worst case scenario if you need to duplicate parts of the code for all three, I don't think that's a problem. Just put it in a library if it needs to be re-used, the only alternative there is that upstream maintains the relevant bits of that duplicate code, which I'm sure you can see why they would be reluctant to do that.
The problem is that these per compositor a.p.i.'s are unstable.
GNOME extensions and KWIN scripts work by allowing one to directly hack the internals of the compositor in unstable ways; they are much like kernel modules and they break from version to version.