That was just example. Because of Wayland's security model of sandboxing applications, none such tool will work. Currently afaik only way to do something similar is using /dev/uinput as does for instance ydotool, but its capabilities are vastly inferior.

What makes you think uinput is less capable? Ultimately everything that uses input uses uinput, it's the source of truth.

For the same reason that it can make sense to say that python is more powerful than C, even though you can obviously do more things with C than with python. Xdotool lets you send keystrokes to a particular window, even if it's not in focus. You can do that with ydotool if you also do some sway IPC, but it's not as convenient, and no one has made a higher-level tool, possibly because it would be a nightmare to make it work with multiple different compositors.

Do you know if there's any standardization effort to support xdotool-like functionality over wayland with some kind of actual security model (using ydotool kind of subverts the security improvements wayland offers unless one does more due diligence than is pleasant to do for quick scripts)

I see your point. No, I'm not familiar with such an effort, though it could probably be incorporated into our existing protocols, perhaps with only minor changes.

Actually, xdotool is the wrong place for this kind of automation. IMO, the optimal place to implement this is in the toolkits, to make it possible to read text and properly click buttons and menus.

I think you have a point, and I agree about this kind of complaint for screencapture where there are APIs on Wayland so you can't point at X-based software that didn't port and say "it's broken"!

However as far as I am aware there is no proper key-capture or key-inserting API in Wayland. There are hacks (IMHO) like bypassing the compositor and reading the events directly but we are still missing a well-defined API that is supported cross-compositor.

I am fine with GNOMEs very limited keyboard shortcut support but I definitely agree that this is a step down from what we had on X.

Automation software like that will never work on wayland (certainly not across different compositors) since it violates the security model.

That's not true. It bypasses the default security model but it is entirely possible (and to be honest I'm surprised there hasn't been progress) for the user (or the compositor automatically) to provide an API that provides the required access to whitelisted applications.

It is just like the web. By default websites don't get to access your camera, but that doesn't mean that camera access is impossible. They just added a way to request camera access with user permission.

Is py37-autokey-for-Wayland possible?

Yes, officially and well contained mechanisms exist (used for virtual keyboards).

Heck, you can even go a layer lower and simulate a keyboard event device, which would work with any window system, past, present and future. Even kmscon.