Interesting. I have to say, after studying the AT / PS2 protocol, I'm surprised most devices work as well as they do. It's not super complicated, but it's not trivial either. There are a lot of corner cases baked-in, and expected behavior is based on the code running on the original IBM implementation of the keyboard controller. You really have to pay attention to the details to reproduce the behavior in a way that seems natural. A KVM has to emulate a keyboard to the computer, and a keyboard controller to the keyboard, so there's plenty of room for error.
In this case, $10 says the behavior that's FUBAR is not of rollover, exactly, but how key repeats are handled. The last key held down should be repeated by sending its scan code continuously at the interval set by the typematic rate parameter (or the default of 10/sec.) Obviously, it doesn't make sense to behave this way with modifier keys, so pressing shift after an arrow key ought to continue sending the arrow key's scan code, but I would bet the KVM is not paying any attention to which key was pressed since it doesn't have any reason to interpret the codes, so it's just repeating the shift key code like it was any ordinary key.
The funny thing is, the KB is probably doing the right thing here and sending the arrow key code. But, either the KVM discards repetitive scan codes if they're already registered as "pressed" in its own buffer, or it disables key repeat entirely on the keyboard end. Either would make sense, since the KVM would need to emulate whatever key repeat interval the selected host asked for, and that might be different between hosts on different channels. So rather than reset the KB every time the input is switched from one host to another, it could just disable the feature on the device end and track key up / down state alone.
