Several problems have arisen with keysyms that require a thorough update of the
keysym standard:

a) Unicode (ISO 10646) has now become the single universal character set
standard that we wished would have been available when keysyms were first
introduced. Keysyms identify both function keys and real characters. For each of
the latter, it is time that we introduce one single official mapping to the
equivalent Unicode character to clarify its exact meaning.

b) For a number of keysyms, the meaning and historic origin has been lost in
time. If we really cannot locate anyone who has a good idea about what some
keysym was once meant to be good for, and where it came from, it is probably
time to declare that keysym officially as deprecated. We should be able to
answer for each keysym questions about its purpose and origin, especially if
there is no obvious mapping to Unicode.

c) No new keysym values should be introduced in the future for real characters.
New values should remain reserved for new function keys (READ EMAIL, EJECT DVD,
EXIT HOLODECK, whatever), which are outside the scope of Unicode. Instead, there
should be a simple algorithmic mapping between any Unicode character and the
corresponding new keysym value. XFree86 has already established the convention
that a Unicode character 0xabcdef is represented by the keysym value 0x01abcdef
unless another widely used keysym was already assigned to it.

d) Some XFree86 developers unfamiliar with the Unicode mapping convention and
the allocation to the keysym space added unfortunately new keysyms for Arabic,
Vietnamese, old Irish orthography and other characters. In the interest of
compatibility, either XFree86 should remove these (or replaces them with
Unicode-based values), or we will have to add them to the X11 standard.

e) We may want to retire additional keysyms for which there are no indication
that they are widely used, in favor of the direct Unicode mapping. An inspection
of the keyboard mapping files in major distributions should give a good idea of
what is actually in use.

f) Even with an algorithm mechanism in place to automatically generate new
keysym values from Unicode positions, we still need a mechanism to respond
quickly to users who want to add additional keysym macro definitions, in order
to keep keyboard layout files readable and free of hex codes.

Overall goal of this revision should be that the relationship between keysym and
Unicode values becomes as simple and long-term stable as is possible without
causing serious backwards compatibility problems.