Would a tool like Auto hotkey if it were implemented on Linux work with Wayland?
AHK lets you run arbitrary code in response to global hotkeys. There is no wayland protocol for applications to register global hotkeys for themselves. Compositors can choose to provide their own hotkey configurations, and what you can do in response to those hotkeys being pressed depends on the compositor. For example in Sway you can register hotkeys to run arbitrary executables. Alternatively, XDP apparently has a portal API for applications to register global hotkeys, but of course it's up to the individual compositors' portal implementations if they implement the API. For example xdpw, used for all wlroots-based compositors like sway, does not.
AHK lets you read and set the mouse position. There is currently no wayland protocol, stable or unstable, for programs to read or set the position of a pointer (if the pointer is not over the program's surface).
AHK lets you introspect arbitrary windows to read the text of a focused textbox, etc. There is currently no protocol, stable or unstable, for programs to implicitly grab the content of surfaces under the pointer, let alone read text of textboxes. At best you can use the XDP Screencast protocol but that only gives you images (AHK integrates with the standard Windows graphics UI API so it can detect textboxes etc), and even then it might pop up a permissions dialog for the user to approve like you would expect for a screencasting program.
AHK lets you insert arbitrary keyboard sequences into the focused window. There is no Wayland protocol for this, but you can just use a new input device through the uinput kernel driver instead of anything Wayland-specific. (ydotool does this.)
AHK lets you read and write to the clipboard. There is an (unstable) wayland protocol for clipboard managers that can be used for this.
> There is currently no protocol, stable or unstable, for programs to implicitly grab the content of surfaces under the pointer, let alone read text of textboxes.
Yes there is, AtSpi, the accessibility protocol. But a normal window-independent `Click, X, Y` would indeed be quite important to have...
I'm wondering if there is a way to somehow get active window position, move windows around etc. using root privileges, without relying on a custom compositor extension. Could not find anything.
Right, "protocol" in that sentence meant "Wayland protocol". I'd forgotten about AT-SPI, and it's true that it solves that problem, though it seems that it also includes API for synthesizing input which would require the compositor to implement something.
>I'm wondering if there is a way to somehow get active window position, move windows around etc. using root privileges
Root doesn't matter, because the compositor isn't running as root either. ie being root won't give you any more privileges over it that just being the same user doesn't.
Things like "active window position", "move windows around", and even the entire concept of "windows" are internal to the compositor. Wayland only talks about surfaces; what the compositor does with those surfaces is up to the compositor. It might display them as windows, or as sides of a 3-D rotating cube, or print them through a printer. So you're not going to get that information from anywhere other than the compositor.
Examples I use: 3 finger swipe to left/right switches desktop in Sway, rebinding caps to esc.