Sure. So we’re starting from the same page:
Independent of the (underline/left arrow and caret/up arrow) font glyph issue, the behavior that Paolo is seeing is exactly what we expect — shift of the key to the right of the 0 is (to Lisp) underline/left arrow, unshifted it’s a hyphen/minus.
At the lowest level Medley operates on unencoded key bits. Presumably once (Interlisp-10) it was ASCII, then it became the unencoded bits for the Alto/D-machine keyboards, then a translation of the (pre-USB and USB) scan codes (e.g., Sun type-3 keyboard, 101(?) key PC keyboard, Sun type-5 keyboard), now it’s the X11 key codes (NOT keysyms), though the raw keyboard (and raw framebuffer) support is still present in the source.
The “physical” keys are passed to Lisp via the 7 * 16 bits key vector (this includes the 3 mouse buttons and 5-key chord keyset)
For the known physical keyboard layouts the tables mapping what the keyboards produce are hardwired (e.g., Sun type-3), but for X11 there are some heuristic adjustments made for slightly different *physical* keys (not glyphs on keycaps) appearing to be present — such as whether the X server is going to report a Delete key or a Backspace key (or both).
At the Lisp level, the 112 bits are known by the symbols in \KEYNAMES, and there is a complicated mechanism for mapping those bits to the (currently NS) character codes and keyboard functions (modifier keys, mouse buttons, interrupt characters).
What we’re NOT currently providing is a set of tables that the user can select from to easily map from the physical keycodes to the characters in their national alphabet (again this is NOT about underscore vs left-arrow; it’s “does this key produce an o-umlaut when typing text”, or “is this the Q key or the A key in my keyboard layout”) — presumably this is not particularly difficult to do, we already have the VIRTUALKEYBOARDS library package which implements this, it’s just that either nobody has built a good set of tables or we don’t know where they are.
In terms of making things happen automatically the problem we run into is that we can’t tell, for all the OSs that we run on, what the user’s expected interpretation of the keyboard is (e.g., macOS’s Xquartz doesn’t implement the keyboard modmap correctly, even for just reading it if not for setting it. Jeremy knows about this but isn’t too interested in fixing it)
So… what’s the real question you want to talk about?
— Nick