It's the keyboard layout.

[WizardStan]

I don't know why you need a Pandora to prove it, the problem is pretty evident

1) Press right shift: a "R_SHIFT Down" event is sent. Game says "ahah, right shift is being pressed"

2) Press other right shift: another "R_SHIFT Down" event is sent. Game says "ahah, right shift is being pressed"

3) Release one of the shifts: a "R_SHIFT Up" event is sent. Game says "ahah, right shift is no longer being pressed"

The game is now no longer aware that one of the shifts is being pressed, whatever that shift may be supposed to do.

We can get into other possible problems, like if it assumes a specific state, and pressing and releasing the button changes the state, you could end up changing it twice. It's a recipe for confusion.

That being said, my keyboard layout had three shift keys as well. I acknowledged the problem and said that it wasn't the end of the world: the odds of it happening are already very small, and when it does happen it should be easily solved by simply letting go of the offending key and pressing it again so it's not like a deadly bug, worst case is you accidentally drop your shields for a moment or whatever that shift button is doing.

Now, THAT being said, it should still only be done if it legitimately brings something useful to the table, enough to balance out the potential risk.

 

[Neelix]

Now, THAT being said, it should still only be done if it legitimately brings something useful to the table, enough to balance out the potential risk.

I also have to agree with Grench that it's a waste of a good key, where we really don't have any to spare, so I reckon it would need to balance against that and the potential risk.

- Neelix

 

[Rockthesmurf]

I think Neelix has a good point about having default layouts without so much printed on the keys, I think having a simple as possible print makes it easier to find the basics. I also agree with the other chap about an attempt to support everything probably means for any specific language, the layout is almost certainly not ideal (meaning people will remap anyway). Therefore perhaps it is better to have a minimal amount printed on the keys and provide default layouts per language (for which I assume wb will be more learned than most about the best layout per country based on statistics) and just let the user switch between layouts.


At the end of the day, most people here live with the Pandora keyboard layout, so despite polls and boycotting, keeping the same amount of international printed keys would be fine and would certainly keep the device more in line with what I suspect most new users would expect from the device.

 

[_jr_]

Nobody has yet demonstrated that having lots of printed symbols does actually help any usecase, while it is obviously detrimental to the beginner (has to hunt even for standard US-QWERTY symbols in a jungle of unfamiliar symbols even with the best possible placement) and not very helpful to the heavy typist (doesn't look much at the keyboard). It isn't at all clear that there is any benefit to be gained compared to just using compose or a customized layout. Therefore just making the best possible US-QWERTY we can (e.g. like some of the proposals already on the table) with only few (or even none) international symbols is the best way to go. It can serve as a base for customized layouts that can be added to the OS at a later point.


The other alternative is a P+n, L+m layout that can easily support German and some Scandinavian languages. According to the poll that could be an acceptable compromise, since the romance languages are seemingly not that important.


And (since it cannot be repeated often enough): double width space is making this business just that little bit more difficult than it should be.

 

[comradekingu]

CK's layout is dead on arrival. It has 4 Alt keys.

Remember, CK is defying wisdom and calling fnmetamodsym "AltGr". That is a problem but it's not why his keyboard fails.
His keyboard fails immediately because he is treating the space bar as two distinct keys when ED has made it quite clear that it is going to be one wide key. Take that extra key away and he'll have a hard time maintaining his "clutter free" stance.

Im calling the button that does F-keys on 60% keyboards (the ones that dont have dedicated F-keys) Fn, since that is most common. It exists in the wild, and it works.


I call AltGr the button that xkbmap calls AltGr. I agree that dualwide space adds problems elsewhere, but what do you want me to do about it, its bad because it is. But it is possible to make it almost up to par, which i have done.

The layout i propose


Has A-Z+3 extras  +4 if you can do without keyboardshift


All 15 US dead diacritics, and a one-press compose key


A language-layer with every letter used for all western-european languages, +shift for big and small versals, no caps needed, and it has the +3 keys by default


Default AltGr available with regional mappings, no imposed anything, this avoids a lot of issues.


Fn available for everything besides F-keys and FN+power


What more is there to implement? Where can it be better?

CK and Saber's layouts have something common at their core that flunks them both.


CK's layout is dead on arrival. It has 4 Alt keys. Only two can be mapped, Left Alt and Right Alt. Right Alt and AltGr are the same thing.


It is just as bad as Saber's having 3 shift keys - also dead on arrival. Only two can be mapped, Left Shift and Right Shift.


Four Alt keys or three shift keys are not minor things to get past. They are fundamental flaws.

So i mapped AltGr/ISO_Level3_Shift  to AltGr, right ctrl, and numpad enter. Along with +q they now all produce @.


altGr+q


KeyPress event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247955695, (-329,109), root542,632),


    state 0x10, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,

Spoiler

    XKeysymToKeycode returns keycode: 92


    XLookupString gives 0 bytes:


    XmbLookupString gives 0 bytes:


    XFilterEvent returns: False


KeyPress event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247955859, (-329,109), root542,632),


    state 0x90, keycode 24 (keysym 0x40, at), same_screen YES,


    XKeysymToKeycode returns keycode: 11


    XLookupString gives 1 bytes: (40) "@"


    XmbLookupString gives 1 bytes: (40) "@"


    XFilterEvent returns: False


KeyRelease event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247955973, (-329,109), root542,632),


    state 0x90, keycode 24 (keysym 0x40, at), same_screen YES,


    XKeysymToKeycode returns keycode: 11


    XLookupString gives 1 bytes: (40) "@"


    XFilterEvent returns: False


KeyRelease event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247955992, (-329,109), root542,632),


    state 0x90, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,


    XKeysymToKeycode returns keycode: 92


    XLookupString gives 0 bytes:


    XFilterEvent returns: False

R_ctrl+q


KeyPress event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247841610, (-321,176), root550,699),


    state 0x10, keycode 105 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,

Spoiler

    XKeysymToKeycode returns keycode: 92


    XLookupString gives 0 bytes:


    XmbLookupString gives 0 bytes:


    XFilterEvent returns: False


KeyPress event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247841734, (-321,176), root550,699),


    state 0x90, keycode 24 (keysym 0x40, at), same_screen YES,


    XKeysymToKeycode returns keycode: 11


    XLookupString gives 1 bytes: (40) "@"


    XmbLookupString gives 1 bytes: (40) "@"


    XFilterEvent returns: False


KeyRelease event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247841873, (-321,176), root550,699),


    state 0x90, keycode 24 (keysym 0x40, at), same_screen YES,


    XKeysymToKeycode returns keycode: 11


    XLookupString gives 1 bytes: (40) "@"


    XFilterEvent returns: False


KeyRelease event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247841960, (-321,176), root550,699),


    state 0x90, keycode 105 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,


    XKeysymToKeycode returns keycode: 92


    XLookupString gives 0 bytes:


    XFilterEvent returns: False

ENTER+q


KeyPress event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247802867, (-591,-224), root280,299),


    state 0x10, keycode 104 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,

Spoiler

    XKeysymToKeycode returns keycode: 92


    XLookupString gives 0 bytes:


    XmbLookupString gives 0 bytes:


    XFilterEvent returns: False


KeyPress event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247802980, (-591,-224), root280,299),


    state 0x90, keycode 24 (keysym 0x40, at), same_screen YES,


    XKeysymToKeycode returns keycode: 11


    XLookupString gives 1 bytes: (40) "@"


    XmbLookupString gives 1 bytes: (40) "@"


    XFilterEvent returns: False


KeyRelease event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247803079, (-591,-224), root280,299),


    state 0x90, keycode 104 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,


    XKeysymToKeycode returns keycode: 92


    XLookupString gives 0 bytes:


    XFilterEvent returns: False


KeyRelease event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247803101, (-591,-224), root280,299),


    state 0x10, keycode 24 (keysym 0x71, q), same_screen YES,


    XLookupString gives 1 bytes: (71) "q"


    XFilterEvent returns: False

 

[codifies]

Here's a small quote from ED's latest post


The keys will be flat, the printing will be on the inside of the cap,


so it can not rub off.


So does that mean after switching off the silly keymap light I'll be able to put my own labels between mat and caps? ...let's hope!

 

[bzar]

@comradekingu: I believe the issue is one level lower. There's no concept of altgr on the kernel driver level. So you'd have to output some other key event, like meta, in its stead and then interpret the meta keys as iso_level_3_shift. At which point you are making a hacky workaround. If it emits a meta event, why not call it meta?

 

[comradekingu]

So if we consider the reason for there not being an AltGr abitrary, its not when you print it on a keyboard. Even if Fn may not be Fn, and AltGr might not be AltGr in the implementation technically, its that way to the user. That is important.

I actually think thats the way it is already, in xmodmap

mod1        Alt_L (0x40),  Meta_L (0xcd)

Which i think comes from /usr/include/X11/keysymdef.h

#define XK_Meta_L                        0xffe7  /* Left meta */
#define XK_Meta_R                        0xffe8  /* Right meta */

#define XK_Alt_L                         0xffe9  /* Left alt */
#define XK_Alt_R                         0xffea  /* Right alt */

I really just wanted to distinguish my way of thinking about it from writing meta on a key, and making it do a mix of things. I have a problem with the mix.

If you only have one key marked meta, in my head it shouldn't be doing shift type things. It wasn't that way on knight or space cadet, and it hasn't been that way since.

I suppose things are different for Meta_R.

Edit: I think the way to avoid problems is having the shoulder altGr be ISO_level5_shift, like neo does

wiki.neo-layout.org/export/2440/linux/X/symbols/level5

// these variants assign various XKB keycodes to ISO_Level5_Shift so that
// the third shift level can be reached

 

[WizardStan]

I agree that dualwide space adds problems elsewhere, but what do you want me to do about it

Stop creating keyboards that treat it as two distinct keys. None of your proposals that do so will work, period. This is not a case of "ED said something but we didn't really discuss it so maybe he doesn't know about how great the alternative is". It has been discussed, arguments have been presented, at the end of it all he has flat out said the double wide spacebar stays. You can claim it's bad design but that is only your OPINION, not fact, and according to polls you are in a minority that believes that.

 

[Saber]

The layout i propose


Has A-Z+3 extras  +4 if you can do without keyboardshift


All 15 US dead diacritics, and a one-press compose key


A language-layer with every letter used for all western-european languages, +shift for big and small versals, no caps needed, and it has the +3 keys by default


Default AltGr available with regional mappings, no imposed anything, this avoids a lot of issues.


Fn available for everything besides F-keys and FN+power


What more is there to implement? Where can it be better?

CK and Saber's layouts have something common at their core that flunks them both.


...


It is just as bad as Saber's having 3 shift keys - also dead on arrival. Only two can be mapped, Left Shift and Right Shift.


...

As I asked _wb_ here, prove it(with your Pandora) that we can't have two keyboard Shift keys, Left and Right, and another Right Shift on L1. Observe and report any conflicts with remaps and when pressing the two Right Shifts simultaneously. I would do this myself, but I no longer have a Pandora handy. Let's see if you can do more than sing it. 

Not interested in applying the effort to testing someone else's bad idea. This falls into the category of, "Even if something is possible, that does not make it a good idea." Three shifts is bound to be confusing AND is a colossal waste of a key.

I expected you’d too squirm out of it.  

It’s not a waste of a key to have both Left and Right Shifts on the keyboard if some people by admission don’t like or want to be forced to use the shoulder Right Shift. 

I don't know why you need a Pandora to prove it, the problem is pretty evident


1) Press right shift: a "R_SHIFT Down" event is sent. Game says "ahah, right shift is being pressed"


2) Press other right shift: another "R_SHIFT Down" event is sent. Game says "ahah, right shift is being pressed"


3) Release one of the shifts: a "R_SHIFT Up" event is sent. Game says "ahah, right shift is no longer being pressed"


The game is now no longer aware that one of the shifts is being pressed, whatever that shift may be supposed to do.


We can get into other possible problems, like if it assumes a specific state, and pressing and releasing the button changes the state, you could end up changing it twice. It's a recipe for confusion.


That being said, my keyboard layout had three shift keys as well. I acknowledged the problem and said that it wasn't the end of the world: the odds of it happening are already very small, and when it does happen it should be easily solved by simply letting go of the offending key and pressing it again so it's not like a deadly bug, worst case is you accidentally drop your shields for a moment or whatever that shift button is doing.


Now, THAT being said, it should still only be done if it legitimately brings something useful to the table, enough to balance out the potential risk.

So, no appreciable “risk” or “problem” to have two Right Shifts, under normal circumstances, since these(or any) Shifts aren’t sticky keys and most people won’t be pressing them in concert(and if they do, nothing measurably Earth shattering will happen as the doomsayers have professed).

 

If, upon the Pyra's arrival at a doorstep, the user were to remap this “other” keyboard Right Shift to something more to their liking, like Yen or Euro, nothing catastrophic would happen either.     

 

Now, THAT being said, it should still only be done if it legitimately brings something useful to the table, enough to balance out the potential risk.

I also have to agree with Grench that it's a waste of a good key, where we really don't have any to spare, so I reckon it would need to balance against that and the potential risk.


- Neelix

Again with the word “risk”. Outright, there is none, only the subjective agenda’s toward favored layouts here spoken by a few. Interestingly, no one rallies against ineptitude in proposals that are built on L2 dependance for common symbols / ? [ ] { }, or require by sustainably flawed design both Shift and Fn/Meta to be pressed for symbols like say _ + : { } ?. 

 

[WizardStan]

If, upon the Pyra's arrival at a doorstep, the user were to remap this “other” keyboard Right Shift to something more to their liking, like Yen or Euro, nothing catastrophic would happen either.

If, upon the Pyra's arrival at a doorstep, the user were to remap the Euro/Yen key to something more to their liking, like an alternate keyboard Right Shift, nothing catastrophic would happen either.

 

[_wb_]

Again with the word “risk”. Outright, there is none, only the subjective agenda’s toward favored layouts here spoken by a few. Interestingly, no one rallies against ineptitude in proposals that are built on L2 dependance for common symbols / ? [ ] { }, or require by sustainably flawed design both Shift and Fn/Meta to be pressed for symbols like say _ + : { } ?. 

I think it is evident that keyboard Meta should be sticky, just like Fn on the Pandora. So my layout does not depend on the shoulder buttons at all for / ? [ ] { }, just like it is possible to input F11, F12, £, ¥, € and Tab on the Pandora.

And I see no reason why keyboard Shift could not be optionally made sticky as well for those people who insist on not using the shoulder buttons.

 

[Saber]

If, upon the Pyra's arrival at a doorstep, the user were to remap this “other” keyboard Right Shift to something more to their liking, like Yen or Euro, nothing catastrophic would happen either.

If, upon the Pyra's arrival at a doorstep, the user were to remap the Euro/Yen key to something more to their liking, like an alternate keyboard Right Shift, nothing catastrophic would happen either.

As long as it's understood about having two Right Shift keys not being the problem some of you have distorted it out to be. 

Again with the word “risk”. Outright, there is none, only the subjective agenda’s toward favored layouts here spoken by a few. Interestingly, no one rallies against ineptitude in proposals that are built on L2 dependance for common symbols / ? [ ] { }, or require by sustainably flawed design both Shift and Fn/Meta to be pressed for symbols like say _ + : { } ?. 

I think it is evident that keyboard Meta should be sticky, just like Fn on the Pandora. So my layout does not depend on the shoulder buttons at all for / ? [ ] { }, just like it is possible to input F11, F12, £, ¥, € and Tab on the Pandora.

And I see no reason why keyboard Shift could not be optionally made sticky as well for those people who insist on not using the shoulder buttons.

Yes, keyboard Meta should be sticky. In your layout though, even if it's sticky, if the person doesn't use the shoulder trigger L2 for Fn/Meta, they would have to tap twice with their left thumb for these: / ? [ ] { }. That's poor implementation.

 

[WizardStan]

As long as it's understood about having two Right Shift keys not being the problem some of you have distorted it out to be.

Oh no, it absolutely is. I already demonstrated why it's a problem. If someone wants to take that risk they are perfectly welcome to.

 

[WizardStan]

no one rallies against ineptitude in proposals that are built on L2 dependance for common symbols / ? [ ] { }, or require by sustainably flawed design both Shift and Fn/Meta to be pressed for symbols like say _ + : { } ?.

1) Yes they do2) There's a distinct difference between "this is a thing that *may* cause confusion" and "this is a thing that can be demonstrated to cause confusion"

edit: "they" being you and CK at least. Honestly _wb_ has bashed out so many keyboards in the last little while I stopped paying attention.

 

[Saber]

I don't know why you need a Pandora to prove it, the problem is pretty evident


1) Press right shift: a "R_SHIFT Down" event is sent. Game says "ahah, right shift is being pressed"


2) Press other right shift: another "R_SHIFT Down" event is sent. Game says "ahah, right shift is being pressed"


3) Release one of the shifts: a "R_SHIFT Up" event is sent. Game says "ahah, right shift is no longer being pressed"


The game is now no longer aware that one of the shifts is being pressed, whatever that shift may be supposed to do.


We can get into other possible problems, like if it assumes a specific state, and pressing and releasing the button changes the state, you could end up changing it twice. It's a recipe for confusion.


That being said, my keyboard layout had three shift keys as well. I acknowledged the problem and said that it wasn't the end of the world: the odds of it happening are already very small, and when it does happen it should be easily solved by simply letting go of the offending key and pressing it again so it's not like a deadly bug, worst case is you accidentally drop your shields for a moment or whatever that shift button is doing.


Now, THAT being said, it should still only be done if it legitimately brings something useful to the table, enough to balance out the potential risk.

As long as it's understood about having two Right Shift keys not being the problem some of you have distorted it out to be.

Oh no, it absolutely is. I already demonstrated why it's a problem. If someone wants to take that risk they are perfectly welcome to.

You have not demonstrated a "problem". Only traced the events, which as far as I can see don't justify this risk spoken of if we have two Right Shifts on the Pyra.

 

[codifies]

if you have to left feet shifts you could just OR the state of the key


Lshift1    Lshift2    OR'd (shift seen)
Up Up Up
  Up        Down     Down
 Down      Down     Down
  Up        Down     Down
  Up         Up        Up
here while left shift 2 is pressed left shift 1 is pressed - only up down up is seen...

However your trouble there is how does some game tell the difference between the shoulder button (a gaming button NOT a key) and the shift key....

mixing gaming buttons and keyboard keys... not a great idea....

The alternative would be to use some other type of shift that maps to the same key characters

so there would be a map of unshifted keys a map of shifted keys and a map of other shift keys which is the same as the shifted map...

 

[Saber]

if you have to left feet shifts you could just OR the state of the key


Lshift1    Lshift2    OR'd (shift seen)
Up Up Up
  Up        Down     Down
 Down      Down     Down
  Up        Down     Down
  Up         Up        Up
here while left shift 2 is pressed left shift 1 is pressed - only up down up is seen...

However your trouble there is how does some game tell the difference between the shoulder button (a gaming button NOT a key) and the shift key....

mixing gaming buttons and keyboard keys... not a great idea....

The alternative would be to use some other type of shift that maps to the same key characters

so there would be a map of unshifted keys a map of shifted keys and a map of other shift keys which is the same as the shifted map...

I don't think we need to go so far as to have a specialized other Shift key map. Assuming I understand you, why would someone press L1(Right Shift) and keyboard Right Shift together anyways and if they felt compelled to, would it even matter if they mistakenly did for these one and done keys? It's been talked before of not having keyboard keys mingling with shoulder modifiers but it never seemed to be more than a smoke without fire issue. 

 

[_wb_]

Again with the word “risk”. Outright, there is none, only the subjective agenda’s toward favored layouts here spoken by a few. Interestingly, no one rallies against ineptitude in proposals that are built on L2 dependance for common symbols / ? [ ] { }, or require by sustainably flawed design both Shift and Fn/Meta to be pressed for symbols like say _ + : { } ?. 

I think it is evident that keyboard Meta should be sticky, just like Fn on the Pandora. So my layout does not depend on the shoulder buttons at all for / ? [ ] { }, just like it is possible to input F11, F12, £, ¥, € and Tab on the Pandora.

And I see no reason why keyboard Shift could not be optionally made sticky as well for those people who insist on not using the shoulder buttons.

Yes, keyboard Meta should be sticky. In your layout though, even if it's sticky, if the person doesn't use the shoulder trigger L2 for Fn/Meta, they would have to tap twice with their left thumb for these: / ? [ ] { }. That's poor implementation.

Not for /, that one can be mashed, much like Tab on the Pandora. But yes, keyboard-only users need two same-thumb taps for ? [ ] { } in my proposal. I don't think that is a big issue, since those symbols are not very important for efficient typing. In natural language, [ ] { } are barely used at all. Question mark is of course used, but not that frequently according to http://homepage.ntlworld.com/vivian.c/Punctuation/PunctFigs.htm :

. full stop: 65.3 per 1000 words

, comma: 61.6

" double quote: 26.7

' apostrophe / single quote: 24.3

- hyphen: 15.3

? question mark: 5.6

: colon: 3.4

! exclamation: 3.3

; semicolon: 3.2

(note that [ ] { } \ | / _ = + ~ are not in this list, presumably because they're too rare in normal text)

By contrast, your layout has the same problem with the diacritics (acute, grave, circumflex), which is a bigger issue since accented letters are pretty common in the languages that use them, and also for F7-F12, which could be annoying because e.g. F11 is often used to toggle full screen, which might be something you frequently need on a small-screen device.

Anyway, I don't think it matters much at all, since all of this only applies to that stubborn subset of people who refuse to use the shoulder button modifiers.

 

[Saber]

Again with the word “risk”. Outright, there is none, only the subjective agenda’s toward favored layouts here spoken by a few. Interestingly, no one rallies against ineptitude in proposals that are built on L2 dependance for common symbols / ? [ ] { }, or require by sustainably flawed design both Shift and Fn/Meta to be pressed for symbols like say _ + : { } ?. 

I think it is evident that keyboard Meta should be sticky, just like Fn on the Pandora. So my layout does not depend on the shoulder buttons at all for / ? [ ] { }, just like it is possible to input F11, F12, £, ¥, € and Tab on the Pandora.

And I see no reason why keyboard Shift could not be optionally made sticky as well for those people who insist on not using the shoulder buttons.

Yes, keyboard Meta should be sticky. In your layout though, even if it's sticky, if the person doesn't use the shoulder trigger L2 for Fn/Meta, they would have to tap twice with their left thumb for these: / ? [ ] { }. That's poor implementation.

Not for /, that one can be mashed, much like Tab on the Pandora. But yes, keyboard-only users need two same-thumb taps for ? [ ] { } in my proposal. I don't think that is a big issue, since those symbols are not very important for efficient typing. In natural language, [ ] { } are barely used at all. Question mark is of course used, but not that frequently according to http://homepage.ntlworld.com/vivian.c/Punctuation/PunctFigs.htm :

. full stop: 65.3 per 1000 words

, comma: 61.6

" double quote: 26.7

' apostrophe / single quote: 24.3

- hyphen: 15.3

? question mark: 5.6

: colon: 3.4

! exclamation: 3.3

; semicolon: 3.2

(note that [ ] { } \ | / _ = + ~ are not in this list, presumably because they're too rare in normal text)

By contrast, your layout has the same problem with the diacritics (acute, grave, circumflex), which is a bigger issue since accented letters are pretty common in the languages that use them, and also for F7-F12, which could be annoying because e.g. F11 is often used to toggle full screen, which might be something you frequently need on a small-screen device.

Anyway, I don't think it matters much at all, since all of this only applies to that stubborn subset of people who refuse to use the shoulder button modifiers.

The stubborn subset as you call it includes this guy. Let's not forget he's an important person when it comes to the Pyra.

As for ? { } [ ], they are sort of important too for non-coders and especially coders. The dead diacritics at u, n, and m in my layout are easy to semi-easy to activate depending on which Fn key is pressed. Same for F11 which I admit is effortless with L2.