Virtual bindings (Motif)
Motif's layer between physical keys and widget behaviour: the code listens for osfCancel and osfHelp, not Escape and F1, and a bindings file decides what those mean on the keyboard in front of you.
Motif had to run on DEC's LK201, Sun's Type 4 and HP's and IBM's keyboards, all with different keys for help, deletion and navigation, and sometimes the same key name with different keysyms. OSF solved it by having the style guide and every widget's translation table speak in virtual keysyms: osfActivate, osfCancel, osfHelp, osfMenuBar, osfBackSpace, osfDelete, osfPageUp, osfPrimaryPaste and some thirty more. At startup they are translated into real keysyms from the _MOTIF_DEFAULT_BINDINGS property on the root window, the .motifbind file in the home directory or the defaultVirtualBindings resource, and failing all of those from a vendor table chosen by the X server's vendor string.
The xmbind tool reads a bindings file and puts it on the root window, and Motif shipped ready-made files per vendor. The effect was that the same binary behaved correctly on different hardware, and that a user with Escape in the wrong place could fix it in one line: osfCancel : <Key>Escape. It was also behind a classic irritation: a Motif program in which Backspace deleted in the wrong direction almost always meant osfBackSpace and osfDelete pointed at the wrong keysym for that keyboard, something xmodmap could not fix because the fault sat one layer up.