[Rd6n6]

Button presses are often handled by state machines at a driver level so that a single “press” only registers as a single press. Otherwise, it will register as a lot of presses because the physical switches bounce on contact. They call this debouncing. Probably, a drivers state machine did not transition out

[dbatten]

This doesn't seem to explain how it would happen after plugging in a new keyboard, or trying to use the on-screen keyboard, though...

[Rd6n6]

Same generic keyboard debouncing in use in all 3 instances on the windows end? I know windows drivers debounce mouse clicks because I had a really old mouse that would double and triple click by accident on Linux but not in windows. I might be wrong, but changing the device might not affect it if the different devices are handled by shared runtime code

[ayewo]

Sounds like a reasonable explanation for physical keyboards—if the new keyboard used by the OP was identical to the keyboard on their machine, I can see how Windows might reuse the same device driver instance since it has already been loaded into memory.

But what about the on-screen keyboard? Do on-screen key presses get routed through the keyboard device driver too?

[Rd6n6]

So fingers bounce when they touch a screen? I wrote a capacitive touch driver once back in uni and we debounced that. I don’t know how windows does it, I’m speculating

[gpm]

It wouldn't be the same debouncer, keyboard input is usually debounced before it reaches the OS, let alone whatever windowing system that an on screen keyboard sends events to.

[Nextgrid]

Pretty sure this would be done at the hardware level, as otherwise this behavior would differ between the BIOS, Windows, Linux & Mac. As far as I know no such debouncing code exists in operating systems for HID keyboards.