Sorry about my annoyance earlier; your assumption wasn’t unreasonable. I am a programmer, after all (though I’m not sure I’d really describe my account on github as “active”). My only contributions to the firmware thus far have been UX ideas, though; the code itself remains quite opaque to me, since the bits that I’ve tried looking at are largely comment-free and I don’t have a great desire to figure out the structure on my own without documentation.
I was mostly trying to make the point that not everyone who wants a configurable keyboard and uses one a lot is a programmer, and that comments like, “Just write a little code” tend to be very off-putting to those people, and get heard as “Give up; you’ll never get what you want”. I, myself, am so bloody-minded that I’ll get what I want whether it’s a colossal waste of my time or not, but I’d much rather not do it that way.
To the specific point: yes, xmodmap and the like would work fine, but I don’t intend to use this keyboard on just one machine (or even just one operating system), and I want it to work the way I expect regardless of how the host is configured, so the keymap has got to be on the keyboard itself. Furthermore, the existing TopsyTurvy plugin has all of the same “cheap reverse-shift hack” problems that the more general solution I’m proposing has, but considerably less configurability. (Also, how is using xmodmap not just another “cheap reverse-shift hack”?) And by doing it on the keyboard, I am “eliminating those problems at the source” – the keyboard is the source of the input, not the OS.