@lexikos: Thank you so much for your response! You have provided some very helpful insight and posed some good questions and ideas!
I looked at the list you mentioned; many of those are actually not the ones I'm referring to—or even on my keyboard. I'm referring to the Kana key; which should not be mixed up with OEM_COPY! Kana is a locking modifier key which changes the output from the Latin alphabet to the Japanese syllabaries. Since AHK doesn't treat it as a modifier, or even recognize that it is locking, it is interfering with its function as such (and accessing the characters in those additional keyboard layers).
Essentially AHK sees the keystrokes but it doesn't recognize them. I have been able to use them to some extent using the (key1 & key2) method (which I use abundantly in my AHK script in general), but it is limited since I can't add any other modifiers and the locking aspect is not recognized; and I haven't been able to work around the issues caused so far.
I haven't used the GetKeyState() yet, but it seem potentially helpful; I need to research and test it to find out. Although it does seem to be a very cumbersome procedure for what would otherwise be very simple if these keys' were recognized for their intended function. The fact that these keys are simply "unknown" has been presenting challenges and limitations on how I can use the keys—at least as far as I can tell... However, as you can certainly infer, I'm not too adept with AHK so it's likely there's something I'm missing or overlooking! So I very much appreciate your all of your feedback and questions!
Have you had a look at the link I provided for KbdEdit? I think that would be very helpful in understanding what I'm talking about. I could try to explain it myself here, but the site's online manual and the help documents will explain things much better than I could! Check out this page specifically:
http://www.kbdedit.com/manual/low_level_modifiers.html
Although my keyboard does have them I've remapped other IME keys which I don't actually need to the LOYA and ROYA modifier keys which are much more useful and make it possible for me to add multiple "shift levels/layers" to my keyboard layout. These rarely used, and other modifier keys which are actually supported by Windows, although documentation is very hard to find, are explained quite well on the page above.
I think that the list of VKs also found on the KbdEdit site and their descriptions/explanations/usage is a great source of collected information which would be very helpful and useful for anyone who is unfamiliar with the extra/additional/unique keys found on various keyboards and would provide and excellent resource.
My reason for using KbdEdit is to support text entry in multiple complex scripts, plus the IPA (International Phonetic Alphabet) without having to change keyboard layouts which can be troublesome and quirky, as well as bothersome—having everything I need on the different layers (modifier states) of ONE keyboard is by far the best, ideal solution!
I definitely understand your concern about expanding the modifier tables and the increased memory involved; even without knowing the actual amounts, it doesn't seem warranted to apply that to all users without JIS keyboards.... Although, KbdEdit (the premium version which I have) can produce standard layouts (installable dll packages on any system without KbdEdit or any other 3rd party software) which remap keys on an ANSI keyboard to the unique keys on a JIS keyboard (such as the left or right modifiers)... Even without the need for entering multiple writing systems those keys could be interesting to other users and keyboard/hotkey enthusiasts.
In any case, perhaps another version of AHK could be made—exactly like the standard edition except with the additional support for the modifiers and extra keys on JIS and ISO keyboards so that only the users who choose to install that version would have to "pay" for their price in memory consumption. Although I am naive about software coding, I don't know how much work would actually be involved in adding the necessary code to provide functionality for these keys. And it may not be as simple or straight forward as I imagine to maintain there after. In my mind once the necessary code for the additional keys was added, from then on any other updates or changes could also be applied to the JIS version with minimal effort. That seems totally plausible to me, and may actually be possible, but I realize that in real life it may not be that simple...
One thing that I can do with KbdEdit is to produce and post a keyboard layout which remaps standard ANSI keys to the special JIS keys, that would at least anyone to test their function even without having a JIS keyboard. It seems like a reasonable and acceptable solution, even if not exactly perfect... Keys such as the Apps Key, Scroll Lock and Insert seem like excellent candidates to be remapped to Kana, Loya and Roya for testing purposes since those keys are rarely used otherwise by most software. This solution avoids changes to the registry or even addition to the AHK script and as a standard keyboard layout can be activated and switched to/from as such with the taskbar widget built into the OS; meaning that it would be a completely temporary change that could be turned on and off easily and quickly without requiring restarts or even loading/unloading an AHK script.
As far as my definition of "support"... I mean: the keys are recognized by AHK and at least the modifier keys given names, and prefix symbols (which do not need be ASCII characters, however, there are some good candidates for additional prefixes: §, ±, ¬, †, ÷, ¡, ¤, ×, «, » which lie within the ASCII range and do not seem to have any other special meaning or use in AHK or any other conflicts that I'm aware of. Of course, I realize that in order to actually use them (without difficulty) in one's scripts, they would need to be able to type them. And for that some changes would have to be made somewhere; one obvious solution would be to add a few lines to the default AHK script (which could be posted for users to add "as is" or customize first. Those lines could even added the default script that installs for that version with instructional comments on how to type them—using shift+alt combinations has worked well for me and has not revealed any conflicts with native OS (or other app's) hotkeys, shortcuts or functions. Of course, it's easier for me to provide support using KbdEdit as that is its designed function, whereas AHK is more suited to executing actions, commands—programmatic access and control (rather than adding mappings for special characters, although it is of course possible).
Are there any reasons why the prefix symbols for the additional modifiers could not be selected from that list of characters (or potentially others... although those seem best suited to me)?
I wish that I were capable of creating the code needed to add this support myself! But my attempts to learn programming languages seems inherently limited by a form of dyslexia that I suffer from. I have been able to come up with "hacks" and coping mechanisms for most of the effects involving most tasks and activities; but it feels like a brick wall when it comes to coding.