I thought it's about preventing inappropriate reactivation? As in, the key slightly bouncing back and forth when you press it, thereby registering two (or more) activations per press
I suppose we should really talk about changes in state rather than activation/deactivation as it's the same problem. But the basic point is that detecting an edge on an "armed" switch is all that's necessary to fire the related event and confirm the state change definitively.
The debouncing logic is about how we determine when to re-arm the switch for the next transition - i.e. how to reject the "false" reversions to the prior state. So it shouldn't have any impact on the "physical action to key-down event" latency in systems with a reasonable steady state. I guess for cases where "pound on the same key again and again as quickly as possible" are in scope it does?
The debouncing logic is about how we determine when to re-arm the switch for the next transition - i.e. how to reject the "false" reversions to the prior state. So it shouldn't have any impact on the "physical action to key-down event" latency in systems with a reasonable steady state. I guess for cases where "pound on the same key again and again as quickly as possible" are in scope it does?