`KEY_MUHENKAN` and `KEY_KPJPCOMMA` both map to the same key in SDL3, but are bound differently

I am reporting this separately from MC-310108 as that ticket concerns items which are explicitly mapped as “Unknown” in SDL3’s keycode list; this instead concerns an unexpected deviation from the specification.

The SDL3 Linux keycode list explicitly states that keys 94 and 95 both should point to SDL_SCANCODE_INTERNATIONAL5: https://github.com/libsdl-org/SDL/blob/855cbec702f246661ff00a0bce9e0683012840c2/src/events/scancodes_linux.h

However, in practice, only the former binds to this - the latter, for some strange reason, instead maps to Not Bound. I have no idea whatsoever why this is the case.

This is easiest to reproduce if you have a Japanese keyboard, since the MUHENKAN key is physically present and I believe the KPJPCOMMA key is as well. A script is attached for those without such a keyboard to hand.

To reproduce (Linux):

• download the Python script attached in the comment section

• open a command window in the same folder it’s present

• go into Minecraft’s key binds menu, then click on a key to rebind

• paste this into the command window and run it: ./simulate-keys 'sleep 2' 'press 94' 'sleep 0.1' 'release 94'

• note what key is registered

• repeat, but with this command: ./simulate-keys 'sleep 2' 'press 95' 'sleep 0.1' 'release 95'

• observe

Expected results: these would bind to the same thing and display a conflict, since in the SDL3 spec they both point to the exact same ID

Actual results: for some reason, the latter just doesn't bind to an existing key ID at all, and ends up becoming unbound instead as though you pressed Escape