As far as I know the keyboard discussions are done. Explanations of why it is as it is should be OK, so long as we restrict to that and not try to argue for changes or different options.
Spanish language support - all European languages support with full-on diacritics really - was given consideration in a few of the proposals. There was loud backlash to those claiming that they made the keyboard too difficult to use or too confusing. To get to that level of support required keys with 3+ printed symbols and for English speakers to ignore top-level printed characters that they would not recognize or use.
There were language polls where it was clear that the majority of prospective Pyra users spoke English, German and French. It was decided that the eventual layout should cater first to English then add German support and a nod to make French usable. French actually came out more usable than it is on a standard French keyboard - which is another discussion.
Some distinction or note should be made, though, that what is printed on the keys in no way limits the capabilities of the keyboard itself. Those symbols will be the default actions of those keys and combinations, but there is nothing stopping an end user from re-mapping existing symbol keys/combinations to something else.
The Pyra has multiple modifier keys.
Left shift, Right shift. One is on a shoulder, one is on the main keypad.
Left Ctrl, Right Ctrl. One is on a shoulder, one is on the main keypad.
Left Alt, Right Alt. One is on a shoulder, one is on the main keypad.
Left Fn, Right Fn. One is on a shoulder, one is on the main keypad.
Left Pyra/Super. Right Pyra/Super. One is on the center keyboard column, one is the screen/lid magnetic switch.
In general practice and default mapping, left shift and right shift will perform the same function. However, if you choose to, Lshift+key could be different from Rshift+key.
Modifiers may be chorded. Using the shoulder buttons, it should be easy to 'mash' combinations of shift+alt+ctrl+Fn. Just using those without Super or creating distinctions between left-right versions of each modifier, those plus any 'normal' key can result in 2^4 different capabilities that can be mapped. 2*2*2*2 = 16.
Theoretically if you had fingers like an octopus, made distinct mappings to left/right versions of each modifier and a magnet to activate the hall sensor for the lid switch, those combinations can expand to a theoretical maximum of 2^10 different results with chorded modifiers and a single 'normal' key. 2^10 = 1024.
If you don't want or need the German vowels, you can software re-map them and simply memorize what you mapped there. If you need more variations than that, there is a lot of space on the Fn+Shift+key layer and Super+key is almost 'empty'. With Fn and Shift on the shoulders, chording those then pressing a 'normal' key should be very easy.
The press-nub-mouse-buttons may seem a bit odd. Tying back to the Pandora, the left nub is the mouse movement. The nubs can either click OR move, not click and move. So - if the left nub is moving the mouse, the right nub-press needs to be the left mouse button to enable click and drag. Left nub click then becomes right mouse button - which generally brings up menus.
@_wb_ also came up with a concept whereby the shoulders could be used for both the modifiers and mouse buttons. It may be a possible software feature expansion if someone decides to build it.
Yes, the keyboard is a compromise through thousands of posts arguing every key's mapping and functionality in fine detail. What came out of that is pretty darn good. I'm sure everyone can find changes that they would want to make in order for it to be better for them, but this needed to be one key mat to service as many as possible while confusing as few as possible.