[varispeed]

You are overcomplicating this. Keyboards shouldn't have any logic apart from scanning and sending key press and release events to the OS.

I press modifier on keyboard A, keyboard A sends key press event to the OS. I press key on keyboard B, keyboard B sends key press event to the OS. I release key on keyboard B, keyboard B sends key release event to the OS. I release modifier on keyboard A, keyboard A sends key release event to the OS.

From the sequence of events, the OS knows that a key was pressed with the modifier and can act accordingly e.g. emit an event downstream that corresponds to the key that should be generated when pressing a modifier.

Scanning the keyboard matrix is no concern for the OS.

[zxter]

Actually, I’m not overcomplicating things—just overexplaining because you mentioned it might be a stupid question.

Your example is valid, and I acknowledged that it’s correct in my first reply. I also added that, in these types of keyboards, there could be special logic to compensate for missing keys or provide additional features for comfort or ergonomic reasons. This means the keys need to communicate with each other and send the final keystroke afterward.

I also noted that almost all keyboards are not entirely "dumb" and include at least a processing unit to scan the matrix—something you agreed they should have—as well as to handle USB or Bluetooth communication. This processing unit can easily be used for the reasons I mentioned above, without requiring extra hardware or additional software/drivers on the OS side. This approach offers a modular, OS-agnostic way to create a custom solution for comfort or ergonomic needs.