ISO_Level3_Shift vs Mode_switch (was: Howto handle modified keys)

[Edgar Toernig]

> The mapping between keys and keysyms and the mapping between
> keysyms and modifier bits are both dependent upon configuration.

This reminds me of a problem recently discussed on the icewm
mailing list.  There was a request to support AltGr in icewm.
Usually, AltGr is mapped to Mode_switch and the patch was looking
for a key with that symbol.  But it seems that nowadays some
keymaps put the symbol ISO_Level3_Shift on that key.  There
was even one report where a key-press gives Mode_switch and
the corresponding key-release gives ISO_Level3_Shift[1].

What's the point of this (new?) symbol?  Wasn't Mode_switch
good enough?  Afaics, the other "shifting" keys (i.e. for kana)
were deliberately set to the same symbol value as Mode_switch.
But this Level3_Shift is special.  This gives a couple of
problems as apps are not prepared to look for this symbol.
Couldn't the keymaps be changed back to use Mode_switch instead
of ISO_Level3_Shift?

Ciao, ET.

[1] This keyboard setting

| Section "InputDevice"
|         Identifier      "Generic Keyboard"
|         Driver          "keyboard"
|         Option          "CoreKeyboard"
|         Option          "XkbRules"      "xfree86"
|         Option          "XkbLayout"     "us,cz_qwerty"
|         Option          "XkbOptions"    "grp:shift_toggle,grp:switch"
| EndSection

produces these two events when pressing and releasing AltGr:

| KeyPress event, serial 28, synthetic NO, window 0x3e00001,
|     root 0x40, subw 0x0, time 46382521, (-82,-55), root:(654,531),
|     state 0x0, keycode 113 (keysym 0xff7e, Mode_switch), same_screen YES,
|     XLookupString gives 0 bytes:  ""
|
| KeyRelease event, serial 28, synthetic NO, window 0x3e00001,
|     root 0x40, subw 0x0, time 46382635, (-82,-55), root:(654,531),
|     state 0x2000, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
|     XLookupString gives 0 bytes:  ""

If you ask me, this looks broken ...