Though, isn't a large portion of the issues in this regard caused by the non-abstraction of the hardware in Tuner, requiring the end-user to do the hard work themselves?
For example, I sometimes need to type using a Japanese keyboard. The way it's implemented on my computer, given that I don't have a special keyboard with extra keys, is that I type out the sounds phonetically in romaji (English characters) and the operating system changes it for me. This is mainly due to difficulties in Kanji, where the same pronunciation can be written in several different ways with several drastically different meanings. Spacebar is used to select between different writings of the same phonetic spelling.
...so when I type "irohanihoheto" it phonetically becomes 「いろはにほへと」 (ignore the bracket quotes, those are [ and ] not "" ). I can't actually type that out into the Tuner and expect it to work. In fact, it doesn't. It takes the input character (like い), turns it into garbage, then deletes it when I exit the tuner and come back to re-edit the file (that chord is non-functional when the cfg file is loaded). If I wanted to actually print the character い using the Twiddler, I would go back into US English mode and type "i" into the Tuner. "ro" "ha" "ni" "ho" "he" "to" etc for the rest.
If I wasn't already used to switching back and forth I would basically need printouts of both layouts to match them up. In fact, if I used the "real" Japanese keyboard layout I would need to spend an inordinate amount of time looking at that table in the documentation, given that I don't actually have such a keyboard on hand.
What would be better would be if the Tuner program read my input at the hardware level rather than the OS level. The way it is now, the burden is on the user to reverse the OS key binding. If I may spitball an idea, ask "What is your current layout" and deal with characters in Unicode in Tuner, but translate them to USB HID codes behind-the-scenes using that layout. It would require having all those layouts recognizable to Tuner, but it's the best I can think of.
@dmar: You probably have an ISO keyboard? One with a split left Shift button, among others? If so, then you need to find a keyboard layout that doesn't make those keys dead (like the regular en-US). Under en-US I believe those keys may be aliased (similar to Alt and AltGr, or "right Alt"). This is where the "undocumented keys" weirdness comes about.
(Just found this out) In OS X (US layout) to accent characters you hold the respective button for a menu, rather than hold to repeat. So holding "e" pops up a menu with è é ê ë ē ė ę numbered 1-7. The Twiddler doesn't allow this, since it doesn't hold keys down per se, and so those characters repeat.
Anyway, I'm getting way, way off topic for here, and this topic should probably be split, but I was reading/testing stuff for the last hour and figured it would be nice to share.
W3 Prior Spec... that I believe is supported, telling how to figure out what key exactly was pressed...?
Fun little tool from here that demonstrates the above. Interestingly enough all Japanese characters produce å on keydown but the correct keyboard character on keyup. Using latest Chrome on OS X.
