From wez@:
```
The optimization I had in mind for stuff like this was to choose an "ordering" for the lock-states and modifiers that you can work through looking for a match - e.g. if you user types Ctrl+Alt+K with CapsLock on then you might look for:
1. CapsLock+Ctrl+Alt-+K
2. CapsLock+Ctrl+K
3. CapsLock+K
4. K

Until you hit an entry that is either explicitly "no character produced", or specifies the character.

This way if CapsLock+Ctrl+Alt+K is the same as CapsLock+K then you won't need entries for K in the Ctrl and Ctrl+Alt tables.  Similarly, if CapsLock+2 is the same as 2 then your CapsLock table will have no entry for 2 either.

Constructing the table to omit entries based on that ordering will be more expensive, though (since you need to do lookups to determine whether things match or not) so perhaps not worth it in general.
```

Will go back to this optimization and revalue it after finished  issue 596066  and  issue 596069 .