Hi knowsnokb, my comment wasn't directed at your question, because I found it was answered by others. By 'irrelevant', I meant irrelevant from my point, which was "how a game can handle different keyboard layouts", a solution that will work for everyone.
As I have stated regular keyboards send standardized scan codes to your computer, what the key cap says doesn't matter. As I have many times said keyboards behave differently because of the software side. Programmable keyboards should send scan codes as well. So you want to try some alternate layout like dvorak/colemak? If you only use the keyboard at home, leave the keyboard at QWERTY. You can add layers and do other fun stuff with it, but leave the basic layer as a QWERTY keyboard. Next, download a keyboard layout creator and make your dvorak/colemak using that. This might sound stupid, because you just bought a programmable keyboard, and thought finally I'm able to use those layouts, but that's against the standards. You can't buy a proprietary flash drive, and then cry because it doesn't fit in a USB slot.
The other option is to do what you said in your OP. Use the programmability to change the layout. This way the keyboard will for the most time work on other computers. Of course then your keyboard still depends on the computers using the same layout within the OS. If it doesn't, your keyboard will not work properly, and it becomes a hassle to make it work.
I think the problem here is that people are confused how keyboards (should) work in the first place. There are of course other ways, but generally manufacturers and OS devs have agreed on using what is known as "Set 2" scan codes.
Consider you buy an English keyboard on English computer. You plug it in and press the key cap that says "A". The keyboard senses this, and sends your computer the scan code "1e". In itself 1e hardly says anything, so within software this will often be translated to "A", and this is what confuses people, because the keyboard is not literally sending "A" to the computer, it's only saying "hey, computer, this guy pressed '1e'". Your computer listens and thinks "hmm... 1e... yes that's the key on the fourth row, second place. Let's ask the OS keyboard layout what that means... Hey, keyboard layout, what's the key on the fourth row, second place?" Then the OS puts up it's reading glasses and reads form the sheet op paper "Let's see... Yes... this guy wants to type the letter 'a'... Hey, active window! The used wants to type the letter 'a'" Now the active window, in this case for example Words listens and says "Ok, I hear you, simsalabim, the letter 'a' shall appear in the text".
Now imagine your a German typing on AZERTY. On that layout the letter Q is where the A is on QWERTY. So once again:
German keyboard, German computer: press "Q": "1e" (translation: 'A') -> Computer -> OS keyboard layout "q" -> active window "q"
English keyboard, English computer: press "A": "1e" (translation: 'A') -> Computer -> OS keyboard layout "a" -> active window "a"
German keyboard, English computer: press "Q": "1e" (translation: 'A') -> Computer -> OS keyboard layout "a" -> active window "a"
English keyboard, German computer: press "A": "1e" (translation: 'A') -> Computer -> OS keyboard layout "q" -> active window "q"
If a game used my explained method, it would go from Computer straight to software, skipping the OS keyboard layout interpretation. That way we can use the "translation" part, because that will be the same for all standard keyboards. Davkols argument against that was that games then cannot print the correct key on screen. For example that the tutorial tells everyone to press "A" to walk left. This may be the case for poorly made games, but I already explained you can, within software, demand to see the OS keyboard layout and thus print out "Q" instead of "A", if the user uses the German layout, or what ever else based on the layout for that matter. If you go about messing up the scan codes on your keyboard, ie. use the programmability to get dvorak/colemak, this becomes totally impossible.