So many walls of text, but I have the feeling we don't really understand one another.
Let me try to explain one last time.
The Pandora has an Fn modifier, which is a hardware modifier (actually not really microcontroller-level hardware, just very low level software, but for our purposes let's ignore that distinction). This has advantages and disadvantages. The advantage is that if you type e.g. Fn+Z to get /, the software does not see the Fn or the Z, it just looks as if you pressed 'the slash key'. The disadvantages are the following: the Fn key itself cannot be mapped to anything else in software, since software does not even see it. In particular, if we would want to have Fn as a shoulder button, then that shoulder button would be invisible to software, which would be a fatal problem for games.
So in the Pyra, we want to have a software modifier, that is, a modifier with key events that can be seen by software. That way we can have it on a shoulder button and still use the shoulder button in games. Let's call the Pyra modifier FOOBAR for now.
Now what I want is to still get the advantages of an Fn modifier, but not the disadvantages. If for example / is at FOOBAR+Z, then what I want to happen when you press FOOBAR+Z, is the following sequence of key events: [FOOBAR PRESSED] [sLASH PRESSED] [sLASH RELEASED] [FOOBAR RELEASED]. Software that knows about FOOBAR can see the FOOBAR events, software that doesn't know about it will simply ignore it and still work fine.
Is this the same as AltGr (also known as ISO Level3 Shift)? No, it isn't. AltGr gives you extra symbols if you already
have a full keyboard. For example, in the US-International keyboard mapping, these are the AltGr symbols (in blue):
there are AltGr symbols on many keys: e.g. AltGr+M gives µ, AltGr+5 gives €, AltGr+slash gives ¿, AltGr+, gives ç, AltGr+Shift+, gives Ç, AltGr+" (so AltGr+Shift+') gives dead umlaut, and so on.
Not everyone needs AltGr. Many people don't even know it exists or how it works. But my point is: it's an additional layer of symbols (or actions),
on top of the normal full keyboard. There can be AltGr symbols on letters, numbers, punctuation symbols, space, and even on the other keys if you want that. But
first you need a normal full keyboard.
So yes, we could call FOOBAR "AltGr" if we want to. But that would be confusing and limiting in many ways. Since AltGr is just the RightAlt key on normal keyboards, it would be very strange to have two normal Alt keys
and two AltGr keys, for a total of four Alt keys. We would have to apply weird tricks to even make that work and still be able to distinguish those four keys. But more importantly: if we already use the AltGr (ISO_Level3_Shift) mechanism for all the keys that are missing on the Pyra keyboard as dedicated keys (F1-F12 and a bunch of punctuation symbols, typically), then someone who wants to have a "real" AltGr key, e.g. one that allows him/her to turn the Pyra keyboard into a US-International keyboard, will find out that this has become impossible: a lot of the Pyra keys will already
have an 'AltGr' label (but not the correct one), and a lot of normal-keyboard keys will
be 'AltGr' keys on the Pyra keyboard (so they can't get a 'real' AltGr label either).
After all, if we put two different keys (e.g. Z and slash) on the same physical key on the Pyra, then if we want to have the same power as a full keyboard, then there have to be potentially 8 different symbols on that one key (even if most users will only use three of them: z Z /). Let's take the example of US-International again:
Z produces z
Shift-Z produces Z
AltGr-Z produces æ
Shift-AltGr-Z produces Æ
slash produces /
Shift-slash produces ?
AltGr-slash produces ¿
Shift-AltGr-slash produces dead hook above, an obscure diacritic used in Vietnamese (unlabeled in the image above, but that's what it does on my keyboard)
so I would expect that if you configure your Pyra keyboard to the setting US-International (assuming it has slash on FOOBAR+Z), then the RightAlt key becomes an AltGr and you get:
Z produces z
Shift-Z produces Z
AltGr-Z produces æ
Shift-AltGr-Z produces Æ
FOOBAR-Z produces /
Shift-FOOBAR-Z produces ?
AltGr-FOOBAR-Z produces ¿
Shift-AltGr-FOOBAR-Z produces dead hook above
This is why I think we should call FOOBAR something else than "AltGr". It could be "Meta", it could be "Hyper", it could be something completely new, I don't really care. Maybe "Meta" does potentially cause some confusion as well (e.g. for Emacs users), so maybe it's not the best choice either. The advantage of "Meta" and "Hyper", "Front" ("Greek") and "Top" is that they are actual modifiers that
historically existed on
some keyboards in the past, but they currently do not exist anymore. So it has some "retro value" to use one of those names. Now "Front" and "Top" would be a bit weird since we don't have big square keys like on a
Space-cadet keyboard, with enough room to put labels on the front of the key or above the main label; most likely our FOOBAR-labels would be to the right of the main label. So that leaves "Meta" and "Hyper". I like the sound of "Meta" (it's a bit philosophical and Greek, which fits well with the geeky Greek-mythology name 'Pyra') and it has a nice symbol
◆ which would look well when using color-coding (since it's a nice solid lump of color). "Hyper" is also nice, it's also Greek, etymologically it is the same word as "Super" by the way (both originate from ὑπέρ). Hyper doesn't have a standard symbol though, so we would have to invent our own. Maybe the upwards arrow with double arrowhead that comradekingu proposed would be a good symbol (
⇮), though it might look a bit too much like regular Shift (
⇧). If the FOOBAR/Meta/Hyper labels are systematically on the right hand side of the keys, then perhaps something like this:
⇛ could work. Anyway, the symbol does not matter that much, the color-coding would do most of the work.
