> For screenshots or screensharing, please use the xdg-desktop-portal API. That should work correctly in X11, Wayland, and within a sandbox.

As Blikkentrekker said, it isn't sufficiently flexible for making a screenshotting app, it is only useful for requesting that some other (possibly compositor native) application take a screenshot and return it to you. Flameshot for example, evaluated using xdg-desktop-portal and determined it wasn't suitable (seeh ttps://github.com/flameshot-org/flameshot/issues/446#issuecomment-774372329). It is also notably missing a way to request a screenshot/screenshare of a single window or of a region of the screen rather than the whole screen.

> For generating fake inputs, a library is being worked on called libei, that also should work in X11, Wayland, and within a sandbox.

Well that's still a work in progress isn't it? My response is about what currently doesn't work, not what will work in the future.

> Generally you should not be using random applications to configure monitor outputs, only your compositor's configuration tool is going to be reliable there.

1. For minimal compositors such as sway, creating an advanced monitor configuration tool that handles hotplugging outputs, or with a GUI is out of scope for the project.
2. Being able to script changing monitor configuration, and bind those scripts to hotkeys is pretty important to me. Thankfully that is pretty trivial with sway, but isn't really possible if the only way to manage monitors is the "compositor's configuration tool". And even if it is, such a script isn't portable between compositors.
3. Maybe it is different with wayland, but my experience in X11 was that configuring monitors with xrandr or arandr was much more reliable than any of the DE's designated monitor configuration tools. And even if reliability is no longer an issue, users might prefer a different UI.

> 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.

Maybe libraries would help, although afaik, such libraries don't currently exist. And some compositors don't have public APIs for some of this functionality at all, and don't really want third party apps to have access, although it is frequently possible to use internal APIs if you can deal with it changing in backwards incompatible ways without any notice. I don't really understand your argument about "upstream" maintaining duplicate code. If there were standardized APIs, there wouldn't be any need for duplicate code.

I did neglect to mention before that all of these are to some extent, somewhat privileged operations, and it does make sense from a security perspective to limit what applications can do these things. However, a big missing piece of wayland is a standard way to grant certain application elevated privileges. From what I can tell most compositors either take the approach of not letting third party apps do a privileged action, or letting all third party apps do a privileged action. Granted it's a difficult problem for a variety of reasons, but the "third party apps aren't allowed to do privileged operations" stance obviously breaks things that worked in X.