On Fri, Sep 27, 2019 at 5:33 PM Eli Zaretskii <eliz@gnu.org> wrote:
> I thought that older versions might perhaps assign different mappings
> to the same keysyms.  If they don't assign any mappings, then I agree
> with you.

XKB lists quite a few keysyms as deprecated, but no keysyms we have
discussed here are affected.
I believe this indicates that they have never been used for another
mapping previously, but I haven't checked extensively.

However, it is also stated in xkbcommon-keysyms.h that:
> * Where the correspondence is either not one-to-one or semantically
> * unclear, the Unicode position and name are enclosed in
> * parentheses. Such legacy keysyms should be considered deprecated
> * and are not recommended for use in future keyboard mappings.

This affects four of the keysyms mentioned:
> #define XKB_KEY_signifblank                   0x0aac  /*(U+2423 OPEN BOX)*/
> #define XKB_KEY_leftanglebracket              0x0abc  /*(U+27E8 MATHEMATICAL LEFT ANGLE BRACKET)*/
> #define XKB_KEY_decimalpoint                  0x0abd  /*(U+002E FULL STOP)*/
> #define XKB_KEY_rightanglebracket             0x0abe  /*(U+27E9 MATHEMATICAL RIGHT ANGLE BRACKET)*/

For two of these keysyms, I managed to find at least one application
that agrees with the current Emacs mapping that we now consider
changing:
> {0xabc, 0x2329},
> {0xabe, 0x232a},
See https://fossies.org/dox/putty-src/xkeysym_8c_source.html

I believe that we should consider carefully whether changing these two
mappings could introduce a regression for some use case, e.g.
PuTTY/ssh/emacs.

My proposed changes are attached.