SUMMARY
xdg-desktop-portal-kde will randomly process sequential key press and key release events out of order, which causes infinite key repetition until the next key press / key release command (if that one is processed in-order). This affects key press/release combos emitted by e.g. KDE Connect, but I believe it's a more general issue with the implementation of the org.freedesktop.portal.RemoteDesktop interface in the XDG portal.

STEPS TO REPRODUCE
1. Emit in quick succession two NotifyKeyboardKeycode DBus calls with state=0 and then state=1 without waiting for the response in between (this can be done using KDE connect)
2. Repeat this several times until the bug is triggered

OBSERVED RESULT
In the buggy state, the key is held down indefinitely rather than a quick press and release. When running a DBus capture (reference command: sudo busctl --user -M you@.host capture | wireshark -i - -k) it is visible that xdg-desktop-portal-kde replies to the state=0 command before the state=1 command, even though this was not the original ordering

EXPECTED RESULT
The key should not be held down indefinitely

SOFTWARE/OS VERSIONS
Operating System: NixOS 24.11
KDE Plasma Version: 6.2.5
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.2
Kernel Version: 6.6.64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7840HS w/ Radeon 780M Graphics
Memory: 60.6 GiB of RAM
Graphics Processor: AMD Radeon 780M

ADDITIONAL INFORMATION
I would provide the PCAP with the buggy DBus calls but apparently wireshark interaction with XDG portal is also broken (!) and I can't save the file (!!)

It seems like this bug is ultimately triggered by something inside Qt which is asynchronously processing DBus events. I'm not familiar with that code, but I assume it's using multiple threads, operating under the assumption that DBus calls don't need to be serialized relative to each other, while in this case they actually do.

Based on my reading of the code, I believe this is an xdg-desktop-portal-kde bug and that the implementation should ensure that DBus calls are serialized appropriately, but it could also be argued that this is a client (eg KDE Connect) problem, where clients should wait for the reply to a NotifyKeyboardKeycode call before sending another one. One issue with that approach that I could see is that if the system is under load, there might be more time in between the press and release call than the user expected, which could still result in unwanted key repetition. Ultimately I think the design of NotifyKeyboardKeycode (and NotifyKeyboardKeysym) is flawed, and there should be an option to send a "press and release" event as one single DBus call. KDE could consider implementing something like this internally.