Here's my mess of a keyboard layout I'm currently using http://www.keyboard-layout-editor.com/#/layouts/76b37f7f0ffddb9ebc76bcb3...
It's the dvorak keyboard layout with caps lock over shifts, caps lock replaced with compose, and a button to flip most of the keys for mostly-one-handed typing.
(I'm using the xev program to read the keycodes/keysyms that follow)

Some terminology:
A key code is a number that represents the physical key on your keyboard. Each physical key has its own number.
A keysym is similar to the text printed on the key. When you press a, the keyboard sends the keycode 38 (assuming a standard 104-key keyboard), your operating system turns that into "keysym 0x61, a" based on your current keyboard layout (assuming you use qwerty, that's where the a is)

With a 104-key keyboard, the button on the fourth row, third column has the keycode 39.
  If you are using the qwerty layout, that button turns into 'keysym 0x73, s'
  I'm using the dvorak layout, so that button turns into 'keysym 0x6f, o'
If you use the colemak layout, that button turns into 'keysym 0x72, r'
  Depending on what keyboard layout you're using, that keycode could turn into any keysym.

Unfortunately, certain programs read the keycode (39) directly, and internally translate that to 'keysym 0x73, s' instead of relying on the operating system to do it.
  Key Krusher (I won't link it, it's hosted on multiple websites) is an example of such a program.
  When I try to type in programs that directly read the keycode, I press button #39, expect to see an o on the screen because that's what my operating system sets the keysym as, but get an s on the screen because the program has its own internal keyboard layout.
  NEVER DIRECTLY READ KEY CODES!

Spiral Knights does correctly read the letter s when I set my operating system to use the qwerty layout, and correctly read the letter o when I set my operating system to use the dvorak layout. This is good. I can assume spiral knights is reading keysyms.

This is how certain keys register (in xev) in certain layouts (I'm sorting them by physical key, with qwerty name) along with what spiral knights does with the input (with [references]):
  s:
    qwerty: keycode 39 (keysym 0x73, s) - types s [1]
    dvorak: keycode 39 (keysym 0x6f, o) - types o [3]
    colemak: keycode 39 (keysym 0x72, r) - types r
    custom: keycode 39 (keysym 0x6e, n) - types n
  semicolon:
    qwerty: keycode 47 (keysym 0x3b, semicolon) - types ;
    dvorak: keycode 47 (keysym 0x73, s) - types s [2]
    custom: keycode 47 (keysym 0x61, a) - types a
  backtick:
    qwerty: keycode 49 (keysym 0x60, grave) - types `
    dvorak: keycode 49 (keysym 0x60, grave) - types `
    custom: keycode 49 (keysym 0xff08, BackSpace) - does nothing (expected it to remove the previous character) [5]
backspace:
    qwerty: keycode 22 (keysym 0xff08, BackSpace) - removes the previous character [4]
    dvorak: keycode 22 (keysym 0xff08, BackSpace) - removes the previous character
    custom: keycode 22 (keysym 0x60, grave) - removes the previous character (expected it to type `)

How spiral knights behaves:
  For the physical key labeled s (keycode 39) [1], it still inputs s if only the keycode is different [2], and it inputs a different letter if only the keysym is different [3].
    It allows the keyboard layout to specify what letter to actually input, because it reads keysym.
For the virtual backspace key (keysym 0xff08) [4], it does nothing if only the keycode is different [5], and it still backspaces if only the keysym is different [6].
    It ignores the keyboard layout, because it directly reads keycode.
Spiral knights is inconsistent. It uses keycode for some keys, and keysym for others. NEVER MIX KEYCODE AND KEYSYM!
  Consistently using only keycode ignores any keyboard layout, and uses the exact key as it's labeled on the keyboard. Being a dvorak user, I wouldn't be able to play this game if it always read keycode.
  Consistently using only keysym ignores the physical keyboard, and lets you rotate each key one to the right if you so wish. The only thing that would keep your text from being entered correctly would then be the lack of a unicode encoding.
Because spiral knights mixes two ways of reading the keyboard, we have the special case [5] where keycode 49 isn't recognized as grave because grave checks for keysym 0x60, and keysym 0xff08 isn't recognized as backspace because backspace checks for keycode 22.

This is just speculation, but I imagine earlier in spiral knights' development, it did read keycode for everything, and only worked in the qwerty keyboard layout with the english language. Then they switched to reading keysym for letters so german/french/spanish keyboards would work with their accented characters, but left other keys like escape/backspace/enter/arrows, either thinking no one would change those, or just not being aware of that oversight.

For the sake of continued internationalization (and the fix of an edge-case bug which shows a previous fix was not complete), either with spoken language, keyboard layout, or with keyboards that are physically designed in different shapes or number of buttons (thumb buttons, chorded keyboards, etc.) please read keysym for all keyboard input (I'm not aware of gamepads having or not having similar problems with text input) and never use keycode (unless keysym turns up blank, which shouldn't happen).

I'm wary of looking up exactly which java functions used are responsible for the mix of keyboard input method, because the Terms of Service don't differentiate between a bug-hunting crusade and a cheat-finding crusade when decompiling or otherwise looking into internals.

Between the suggestion to allow a knight to keep moving while the player is talking, and the bug that input is not being processed correctly, the input bug overrides the usability suggestion in this thread.

In /usr/share/X11/xkb/keycodes/evdev, I can change the lines <TLDE> = 49; <BKSP> = 22; to <TLDE> = 22; <BKSP> = 49 to have xev show (left to right) keycode 49 (keysym 0xff08, BackSpace) and keycode 22 (keysym 0x60, grave).
This effectively swaps the two buttons, in a way spiral knights can't see through (I expected it to only change keycode, not both). Unfortunately, it's applied before any keyboard layouts, so I can't toggle it without re-editing the file again.
So this is just a proof-of-concept that you can still fool a program that reads keycode (when it should be reading keysym) by getting closer to the keyboard.

By the way, to actually test this problem yourself, open /usr/share/X11/xkb/symbols/us (normally only writable by root) and make the top of the file look like this


partial alphanumeric_keys modifier_keys
xkb_symbols "basic" {

name[Group1]= "English (US)";

// Alphanumeric section
// key <TLDE> { [ grave, asciitilde ] }; //comment out this line
key <TLDE> { [ BackSpace, BackSpace, BackSpace, BackSpace ] }; // add this line
key <BKSP> { [ grave, asciitilde, dead_grave, dead_tilde ] }; // add this line

and then restart something to make the new file take effect - keyboard layout, windowmanager/login, X windows, whichever does it.
This swaps the two buttons only in the default us (qwerty) layout, and only by keysym (and to repeat myself, which spiral knights reads for tilde but not for backspace, so tilde does nothing, and backspace still does the same thing)

I created a new keyboard layout just for testing http://www.keyboard-layout-editor.com/#/layouts/5d9f2dd9aab963bfb17df248... it moves every key (assuming a 104-key keyboard) one to the right.

I set my keyboard layouts (If I don't just use the kde widget) by the command
setxkbmap -layout us,us,us,us -variant dvorak,dvorak-mirrored,,offset-test
This sets the layouts to be, in order, dvorak, flipped dvorak for the other half of one-handed typing, regular qwerty, and 1-key shift.
I change which keyboard layout is currently active through the kde widget (I don't know the actual command for it)

A REAL workaround:
If I want to use the dvorak-mirrored layout, I say
setxkbmap -layout us,us,us,us -variant dvorak-mirrored,dvorak,,offset-test
and set the kde widget to the first layout.
If I want to use the offset-test layout, I say
setxkbmap -layout us,us,us,us -variant offset-test,dvorak,dvorak-mirrored,
and set the kde widget to the first layout.

¡Spiral Knights, Kate, and BZFlag all work perfectly when my currently-selected keyboard layout is the first in the list!

Somewhere, there's a difference in the interpretation of a secondary layout. It may be that a program is using a library incorrectly, it may be that a library itself is doing it wrong, and some programs inherit that. It may be that something is reading the first keyboard layout as the base for a partial secondary layout, when it should be reading qwerty as the base. I'll try to track down whether it's the keyboard layouts themselves (.xkb files), the layout list (setxkbmap), the selector (the kde widget), a library (Bzflag uses SDL, if it makes any difference), or the incorrect use of a library (like how hunspell loses multi-dictionary as a library).
Because dvorak-mirrored and offset-test are both custom layouts created by myself, I can't trust that they are formatted correctly. I'll look for another layout that works when first, and breaks when after qwerty (or a similar mostly-standard layout), and add to my list of programs that do and don't read secondary keyboard layouts correctly.