There's also wstroke, an easystroke fork for Wayfire (wayland compositor).

Port wstroke to other compositors beyond Wayfire. Actually, I don't think this has to be difficult, at least for compositors written in C/C++: what you need is to hook into the code handling mouse events, while the rest of the codebase (outside of easystroke_gestures.cpp can likely be reused without much changes). What could be an issue is that you have to compile everything together, so this needs either support from the compositor devs or an existing infrastructure for external plugins as it is the case with Wayfire. This can become more difficult if C++ plugins are not supported, e.g. GNOME Shell only supports extensions written in JavaScript; in theory, porting the gesture code could be possible though, just more work

https://github.com/dkondor/wstroke/issues/1#issuecomment-995225184

I had a look at wstroke, and added some rudimentary info to the Prior Art section. Architecturally, it's still the same as an X11 gesture recognizer would be: it expects full access to raw mouse button and motion data, and couples this with the code to perform actions. Nothing wrong with that if the compositor decides to expose full access to raw mouse button and motion data, which Wayfire allows for plugins apparently. But KWin to my knowledge does not allow that, and perhaps shouldn't either.

I feel like we can aim a little higher and make a proper Wayland protocol (or two) with separation of concerns. This would correspond to the other option that was mentioned in the same bullet point list you linked to above:

Create a new Wayland protocol that allows an external program to handle gestures (basically track the mouse and carry out some actions, like send keypresses). This would allow a generic way to have an Easystroke port that works on all compositors that support this new protocol, but you would have to convince compositor developers to actually support such a protocol. This would have the security issues mentioned above, but there are already protocols that allow clients to perform privileged actions and some discussion on a mechanism to restrict access to security critical protocols, e.g. here. It could make sense to raise this issue in the wayland-protocols repository, mentioning that you're interested in Easystroke-like mouse gestures generally.

• how to deal with conflict - mouse button press vs. mouse button gesture start (e.g. RMB)
• in KWin directly vs. KWin script vs. send events to app (this one doesn't sound great)

I think this would need to be an InputEventFilter directly in KWin. I think only such filter can interrupt input without adding any latency.

• specific to mouse, or can it also be enabled for touchpad gestures?

If implemented within KWin there is no real restriction.

• could port shape recognizer from mouse-actions to KWin (possibly rewrite in C++)

Porting from rust (as I am a fan of Rust), feels weird but why not. It has MIT license, so on that front that's fine. At least it gives some heuristic and old khotkeys code could be of use as well.