It's the keyboard layout.

[グレェ]

Wow, 64 pages in this forum thread on keyboards.

Input methods, clearly are a popular bike shedding subject! ^_^

I am from the USA, and grew up with various QWERTY forms, though I feel as though such things were more or less perfected in the Sun, NeXT and Amiga keyboards, with a saner placement of the control key (where most other keyboards now place a caps lock key). I have also studied Japanese for much of my life, and lived in Germany for a while last year (and dealt often with their QWERTZ). For me, the best keyboard currently made is Apple's Japanese keyboard, which is a six row QWERTY with some extra modifier keys. Not every key has a glyph marking corresponding to what it can do, making figuring out _ and \ a bit challenging as they are essentially invisible; moreover there are a bunch of other keys labeled in a non-romanized font that gets confusing.

Regardless, particularly with gaming as an application, key bindings can, and often are, remapped. Just go use mednafen for a while if you don't believe me. 

However, what I find more worthwhile than discussing specific key mappings (which vary by I18N) or reading back on 64 pages of threads.

How many keys do you have?

If you look at small form factor devices with full keyboards, those are frankly, the BEST.

Some examples that come to mind: Danger's Hiptop (more widely known as the Sidekick) which had a 5 row QWERTY keyboard.

The Android G1/ADP1, also had a 5 row QWERTY keyboard.

The Samsung Sidekick 4G (an Android device, attempting to mimic the older Danger mold) also, a 5 row QWERTY keyboard.

The IBM PPC110 Thinkpad (released only in Japan, a full 486 laptop that was about the size of a 3.5" floppy disk) had a 7 row QWERTY keyboard: http://regmedia.co.uk/2007/06/12/ibm_thinkpad_7.jpg

Meanwhile, the Japanese Sharp Galapagos 005SH (a glasses free 3D gaming Android device with bundled in Capcom arcade classics) had a 4 row QWERTY keyboard, but D pad.

Ostensibly, the Open Pandora, had a 4 row QWERTY keyboard, but it broke the continuity of the number row.

But really, I would recommend looking at the HTC Android G1/ADP1, the Samsung Sidekick 4G, the Danger Hiptop/Sidekick as references for fitting a 5 row QWERTY keyboard into a small form factor that is actually insanely good to use.

The space key placement on the Open Pandora is terrible.

Talking about omitting ESC keys, or placing a control key in a bad place. . . just look, others have done great jobs in small form factors. Sure, some compromises are likely to be made, but fewer than you may think. If IBM could fit a 7 row QWERTY into such small dimensions, I am sure the Pyra can be perhaps not quite as insane, but still much better than the Open Pandora was. ^_^

Regardless, I am excited about the platform and wish you good luck on the continued development!
 

 

[_wb_]

We don't have room for a 5, 6 or 7 row keyboard like the PalmTopPC110:

We just don't have the vertical room for that, because a large portion is already taken by the dpad/nubs/action buttons.

The PC110 was also quite a bit larger than the Pyra: 158 x 113 x 33 mm for the PC110, compared to 140 x 84 x 29 mm for the Pyra.

OTOH, since we already have a dpad and shoulder buttons as modifiers (and both are superior mechanisms compared to their normal keyboard implementation), we don't really need that bottom row of the PC110 keyboard. The Pyra keyboard has actually 5 rows if you count the five keys at the top (which includes the power button) and the 6 action buttons (which would probably be home/end/pgup/pgdn/ins/del). So compared to the PPC110, the only row that is missing, is the dedicated F-keys row.

Unfortunately, the Pyra keyboard has not enough keys per row to implement a completely full keyboard, including all of - = [ ] \ ; ' , . / as primary keys.

The physical layout of the keyboard has already been decided, the PCB is finished, so we're now discussing the labels on the keys, not the physical layout.

 

[bzar]

Additionally, some of those examples are designed mostly for text input and not for shell use or programming. They may be good for texting and the odd shell command to open IRC screen, but not for much more.

 

[_wb_]

Thanks to Wikipedia I made the hopefully accurate list below for all these specific language orthographies. Every one of them passed with my v3.0 layout with the assumption that the user isn't hopping from one nationality to another. The exceptions, in only a few cases, are the "very rarely" types which were inconsequential. Bolded letters means they'll need to be(and can be) remapped over one or more of the keys for ä, ö, ü, ß, or the three diacritics(dependent on which are or aren't required for the native alphabet). 

My v3.0 layout again:

Spoiler

Spoiler

Dutch: á, é, ó, ú, ë, ï, and very rarely used â and é.

In Dutch we also need ü and ö for Dutch words like "reünie", "vacuüm", "coöperatie", "coördineren", "zoölogie" (ä only for loanwords like "salonfähig"), and ê for words like "enquête", "gêne", ç for words like "reçu", "façade", "Brabançonne" (the name of the national anthem in Belgium, where most people speak Dutch).

So your suggestion is that we remap ä and ß to ë and ï and just avoid writing some words? Or perhaps ü to ¨ and ß to ç, then everything can be typed. I guess that could work. It would be tricky to remember (after all, we don't need those special letters very often, so it's not something you would get used to quickly), but possible. Just using Compose sequences would be what I would most likely do in practice though.

If remapping üöäß to language-specific letters is good enough to say a language "passes", then yes, you can "support" a lot of languages. But I don't think it's very user-friendly to have to remember remappings. E.g. for Spanish you would have to remember that the key labeled ä is really a ñ. Or was it ö?

Moreover, multilingual needs do exist. "Multilingual speakers outnumber monolingual speakers in the world's population.[1]", says Wikipedia. In Belgium, the official languages are Dutch, French and German, and most people use at least two out of those three. Switzerland has four official languages. Also some people like to talk about names of cities and other persons using the correct spelling. If I want to say something about Slavoj Žižek, it's nice to be able to spell his name correctly, for example.

So I think a more multilingual layout like

http://www.keyboard-layout-editor.com/#/layouts/d7e5a0dab3f707566068e641e29c84d9

is worth the little bit of extra "clutter".

 

[ible]

If I want to say something about Slavoj Žižek, it's nice to be able to spell his name correctly, for example.

Well, only if you want to say something nice

I do think international "clutter" is a nice selling point, especially in Europe.  We'll have to see what ED prefers, if he just wants to go English and German mostly.  (That is the biggest market, apparently.)  But In case ED only wants hardware keys up top (i.e., _wb_ can't put Esc up top), with a little more natural spots for vowels and other accented symbols:

http://www.keyboard-layout-editor.com/#/layouts/1417479de73c9231d7e258fd0eb779a4

But if there's no restrictions on keys up top, I thought it more natural to put functions you might actually want to use in game on the outer upper keys.  Those should be quite easy to press in a game using the nubs -- here's a mouse button added (M1 and M2):

http://www.keyboard-layout-editor.com/#/layouts/53bcbd5cbc5313c5acf8b5e9cbd8cb81

how certain buttons work in the spoiler.

Spoiler

Here the LED button works like _wb_ had in a few layouts previous -- shift to get keyboard LEDs, Meta to dim. The hardware button could be reduced to one gear button symbol, but this is the functionality I might cram in it if I could.  Perhaps the mouse button could be put in as M3 and M4 (mouse 3 and 4), so they don't duplicate nub presses, but I would probably have a default map to M1 and M2.  (Or vice versa:  hardwire the nubs to M3 and M4, and make them default to M1 and M2.)

 

[Eight Bit]

So I think a more multilingual layout like http://www.keyboard-...068e641e29c84d9is worth the little bit of extra "clutter".

Your best keyboard so far imo. I could live with this lay-out even though I'd rather have the language specific letters hidden and/or on the right side of the keyboard and the common symbols opposite of Fn. I like the fact that you changed your mind and made it pandora compatible with the Fn on the bottom right.

 

[Saber]

Thanks to Wikipedia I made the hopefully accurate list below for all these specific language orthographies. Every one of them passed with my v3.0 layout with the assumption that the user isn't hopping from one nationality to another. The exceptions, in only a few cases, are the "very rarely" types which were inconsequential. Bolded letters means they'll need to be(and can be) remapped over one or more of the keys for ä, ö, ü, ß, or the three diacritics(dependent on which are or aren't required for the native alphabet). 

My v3.0 layout again:

Spoiler

Spoiler

Dutch: á, é, ó, ú, ë, ï, and very rarely used â and é.

Estonian: ä, ö, ü, õ, š, ž.

Finnish: å, ä, ö, and very rarely used š and ž.

French: é, à, è, ù, â, ê, î, ô, û, ë, ï, ü, ç, and very rarely used ñ and ÿ.

German: ä, ö, ü, ß.

Hungarian: á, é, í, ó, ú, ö, ü, ő, ű.

Italian: à, è, é, ì, í, î, ò, ó, ù, ú.

Norwegian: é, è, ê, ó, ò, â, ô, å, æ, ø.

Polish: ć, ń, ó, ś, ź, ł, ż, ą, ę          

Portuguese: á, â, ã, à, é, ê, í, ó, ô, õ, ú.

Spanish: á, é, í, ó, ú, ñ.

Swedish: å, ä, ö.

Turkish: â, î, û, ö, ü, ç, ğ, I, İ, ş.

Spoiler

In Dutch we also need ü and ö for Dutch words like "reünie", "vacuüm", "coöperatie", "coördineren", "zoölogie" (ä only for loanwords like "salonfähig"), and ê for words like "enquête", "gêne", ç for words like "reçu", "façade", "Brabançonne" (the name of the national anthem in Belgium, where most people speak Dutch).

So your suggestion is that we remap ä and ß to ë and ï and just avoid writing some words? Or perhaps ü to ¨ and ß to ç, then everything can be typed. I guess that could work. It would be tricky to remember (after all, we don't need those special letters very often, so it's not something you would get used to quickly), but possible. Just using Compose sequences would be what I would most likely do in practice though.

If remapping üöäß to language-specific letters is good enough to say a language "passes", then yes, you can "support" a lot of languages. But I don't think it's very user-friendly to have to remember remappings. E.g. for Spanish you would have to remember that the key labeled ä is really a ñ. Or was it ö?

Nothing tricky(or sneaky maneuvering here) about remapping in my layout. I have full confidence the Spanish user can remember they had mapped their ñ onto ß, or n. Accounting for the dead key diacritics Circumflex, Grave, and Acute, which reduce the bulk of the need for local letter outputting with Compose, my layout, moreover, has ä, ö, ü, and ß for any additional and optional reassignments handy. Most users will find their principal language is comfortable to type on the Pyra keyboard. 

So I think a more multilingual layout like http://www.keyboard-layout-editor.com/#/layouts/d7e5a0dab3f707566068e641e29c84d9  is worth the little bit of extra "clutter".

... I could live with this lay-out even though I'd rather have the language specific letters hidden and/or on the right side of the keyboard and the common symbols opposite of Fn. I like the fact that you changed your mind and made it pandora compatible with the Fn on the bottom right.

Nail meet head right there. It's very shoulder Fn/Meta biased as are all his layouts by his own admission. Common(high frequency of use) symbols / ? ' " ; : [ ] { } - _ = + should be on the opposite side of the keyboard modifier that constructs them. It flagrantly violates that what should be obvious ergonomic. 

 

[sebt3]

Please, the reply for this was 22 pages ago...

 

[_wb_]

So I think a more multilingual layout like http://www.keyboard-...068e641e29c84d9is worth the little bit of extra "clutter".

... I could live with this lay-out even though I'd rather have the language specific letters hidden and/or on the right side of the keyboard and the common symbols opposite of Fn. I like the fact that you changed your mind and made it pandora compatible with the Fn on the bottom right.

Nail meet head right there. It's very shoulder Fn/Meta biased as are all his layouts by his own admission. Common(high frequency of use) symbols / ? ' " ; : [ ] { } - _ = + should be on the opposite side of the keyboard modifier that constructs them. It flagrantly violates that what should be obvious ergonomic. 

Yes, my layouts are optimized for handheld use (i.e. shoulder modifiers), while they also work well (though slightly less efficiently) for tabletop use.

I think that makes sense. It is a handheld, after all.

I've said this many times now that not everyone will use the shoulder Fn/Meta modifier with the keyboard.

I honestly don't understand why they wouldn't, if the device is held in the hands.  Frankly if people want to make things difficult for themselves by not taking advantage of all the available modifier buttons that's their own lookout.  

Once the device is on a dock or desktop the ergonomics change and having the modifier on the same side of the keyboard is less of an issue.

New users will of course need to be educated, and  I think a good way to make it known to new users that the modifiers are on the shoulder buttons  (and that home, end, etc are on the gaming buttons) is  by putting up a key map as the default wallpaper.

- Neelix

 

[Neelix]

Please, the reply for this was 22 pages ago...

You mean all this time we've been arguing in circles this whole time??   We'll need to start leaving a trail of diacritics so we can see where we've been.

- Neelix

 

[Saber]

So I think a more multilingual layout like http://www.keyboard-...068e641e29c84d9is worth the little bit of extra "clutter".

... I could live with this lay-out even though I'd rather have the language specific letters hidden and/or on the right side of the keyboard and the common symbols opposite of Fn. I like the fact that you changed your mind and made it pandora compatible with the Fn on the bottom right.

Nail meet head right there. It's very shoulder Fn/Meta biased as are all his layouts by his own admission. Common(high frequency of use) symbols / ? ' " ; : [ ] { } - _ = + should be on the opposite side of the keyboard modifier that constructs them. It flagrantly violates that what should be obvious ergonomic. 

Yes, my layouts are optimized for handheld use (i.e. shoulder modifiers), while they also work well (though slightly less efficiently) for tabletop use.

I think that makes sense. It is a handheld, after all.

I've said this many times now that not everyone will use the shoulder Fn/Meta modifier with the keyboard.

I honestly don't understand why they wouldn't, if the device is held in the hands.  Frankly if people want to make things difficult for themselves by not taking advantage of all the available modifier buttons that's their own lookout.  

Once the device is on a dock or desktop the ergonomics change and having the modifier on the same side of the keyboard is less of an issue.

New users will of course need to be educated, and  I think a good way to make it known to new users that the modifiers are on the shoulder buttons  (and that home, end, etc are on the gaming buttons) is  by putting up a key map as the default wallpaper.

- Neelix

Will this "education" you and Neelix talk of involve a large T.V. screen in a dark room with some hard paddling and gummi bear rewards?  

I don't want the old or new user to be subjugated to "triggergate". I want the device to work without this constraint.

 

[_wb_]

Here is a layout with the punctuation you need for natural language all on the left:

http://www.keyboard-layout-editor.com/#/layouts/fb9f7d7dbe0e66f38f70fd7a01896878

(I also made the keys a bit thinner so they have a more realistic aspect ratio)

Features:

• , . ' " ; : / ?  all on the left, so you can easily input natural language without using shoulder Meta.
• - is a Meta-mash combo
• the ÜÖÄ triangle has Ü on U
• ç and ñ on C and N

Disadvantages:

• it looks more like an arbitrary splatter of symbols than some of my other proposals

 

[Urben]

I cant say it looks bad, having them at one place makes it easier to know where to look for it.

 

[_wb_]

Here another one, now with the "foreign stuff" clustered in the middle:

http://www.keyboard-layout-editor.com/#/layouts/657a91653495a21fe551349c3ee89ba2

The [] /|\ {} cluster is strategically positioned for the command line: ~/ and ./ are easy combos, for example.

On the right you have ? ; : in their expected US-QWERTY locations and around space, for easy [punctuation space] combos.

I kinda like this one.

 

[Urben]

Yea looks very charming!

But from my own experience I think things which are looking good come with a downside...

 

[_wb_]

Still about: http://www.keyboard-layout-editor.com/#/layouts/657a91653495a21fe551349c3ee89ba2
 
I made a diagram to verify that everything is covered. I am trying to be exhaustive here in order to not forget anything.
 
The basis for this exercise is the Multilingual European Subset 1 (MES-1), which is a standardized subset of Unicode which aims to cover all Latin-script languages used in Europe (which implies that North and South America are also covered if you don't consider obscure indigenous languages). MES-1 is the most recent version of a standardization process that goes back to ISO/IEC 6937.
 

This is the list of languages covered by MES-1:
Afrikaans, Albanian, Basque, Breton, Catalan, Croatian, Czech, Danish, Dutch, English, Esperanto, Estonian, Faroese, Finnish, French, Frisian
Galician, German, Greenlandic, Hungarian, Icelandic, Irish Gaelic (new orthography), Italian, Latvian, Lithuanian, Luxemburgish, Maltese,
Manx Gaelic, Moldavian (new orthography, with restrictions), Northern Sami, Norwegian, Occitan, Polish, Portuguese, Rhaeto-Romanic,
Romanian (with restrictions), Scottish Gaelic, Slovak, Slovenian, Lower Sorbian, Upper Sorbian, Spanish, Swedish, Turkish, Welsh

Here is the chart:
https://docs.google.com/spreadsheets/d/1ok7-yZKT2pJ4_3o0LZTLytMxqnQGc5yQtc3mHyyuES4/edit?usp=sharing

It should include all 335 characters of MES-1. For every single character, it is indicated how you can type it most efficiently in my layout proposal. Yes, it is a bit of a mess. Languages are messy things.

I found one 'bug' in my assumptions: even though Ł can in a sense be considered as L with kreska, which is a Polish acute, we cannot use dead acute + L for Ł ł because L with acute (Ĺ ĺ) also exists (in Slovak), which is by the way not to be confused with L with caron (Ľ ľ) where the caron usually looks like an apostrophe. To solve this, and to also cover the Croatian Đđ, the Danish/Norwegian Øø, the Maltese Ħħ and the Northern Sami Ŧŧ, I decided to follow the Compose convention and use slash / for letters with a stroke or crossbar. Shift+/ can act as a dead diacritic to produce ĐĦØŁŦđħøłŧ.

I also added Shift+minus for dead macron, to get ĀĒĪŌŪāēīōū.

Here are the conclusions in terms of coverage:

The only letters that are not covered in two thumb presses by my layout are the following: Ææ Œœ Þþ Ðð Ŋŋ ĸ. For these you would need a Compose sequence (AE OE TH DH NG KK respectively), which takes three thumb presses. This makes typing Danish (5.5 million speakers), Faroese (66,000), Greenlandic (60,000), Icelandic (330,000), Northern Sami (~25.000) and Norwegian (5 million) less efficient to type. (For French, the missing Œœ is not a big deal).

The biggest problem is for Danish, where Æ has a letter frequency of 0.97% (which is between that of K and V in English). In Norwegian, Æ has a letter frequency of 0.26% (about the same as the letter J in English). So having an easier way to type Æ would be useful. Perhaps it would be justified to remove § (so you would have to do Compose S O) and replace it with Æ. On the other hand, it is weird to have one-thumb Æ but still need two thumb presses for Å and Ø, which are more important letters than Æ in Danish and Norwegian. So I think that it makes more sense for Norwegians and Danish people to just remap Å Ø Æ (in their favorite positions, which differs between Danish and Norwegian keyboards) over Ü Ä Ö, which is probably something they are somewhat used to do if they ever typed on a German or Swedish keyboard before.

The other symbols (Þþ Ðð Ŋŋ ĸ) for which you are forced to use the Compose method, are only used for Faroese, Greenlandic, Icelandic and Northern Sami (total number of speakers: less than 0.5 million).

Note: do not confuse the Ðð (eth) of Old English, Faroese and Icelandic, which I don't efficiently support, with the Đđ (dyet or crossed D) of Serbo-Croatian languages (~19 million speakers) [and, incidentally, Vietnamese (~75 million)] which is available in two thumb presses.

To go back over the list of languages: I have indicated the languages that are supported perfectly in bold (meaning that all letters are available in one thumb press, or two thumb presses if the letter would also require two thumb presses on a standard keyboard for that language). The others need at most two thumb presses per letter, which is still quite reasonable, except the ones in red which need Compose sequences (so three thumb presses) for some letters.

Languages with more than 10 million speakers are in a larger font, and languages with more than 100 million speakers are in an even larger font.

Afrikaans, Albanian, Basque, Breton, Catalan, Croatian, Czech, Danish, Dutch, English, Esperanto, Estonian, Faroese,

Finnish, French, Frisian, Galician, German, Greenlandic, Hungarian, Icelandic, Irish Gaelic, Italian, Latvian, Lithuanian,

Luxemburgish, Maltese, Manx Gaelic, Moldavian, Northern Sami, Norwegian, Occitan, Polish, Portuguese, Rhaeto-Romanic,

Romanian, Scottish Gaelic, Slovak, Slovenian, Lower Sorbian, Upper Sorbian, Spanish, Swedish, Turkish, Welsh

I'm quite happy with this coverage. The Scandinavian languages (including the insular ones) are the biggest remaining problem. I see no easy solution for them, except just using something US-International or remapping üäö to åæø.

 

[Hồng Thất Công]

Thanks to Wikipedia I made the hopefully accurate list below for all these specific language orthographies. Every one of them passed with my v3.0 layout with the assumption that the user isn't hopping from one nationality to another. The exceptions, in only a few cases, are the "very rarely" types which were inconsequential. Bolded letters means they'll need to be(and can be) remapped over one or more of the keys for ä, ö, ü, ß, or the three diacritics(dependent on which are or aren't required for the native alphabet).


My v3.0 layout again:

Spoiler

Spoiler

Dutch: á, é, ó, ú, ë, ï, and very rarely used â and é.


Estonian: ä, ö, ü, õ, š, ž.


Finnish: å, ä, ö, and very rarely used š and ž.


French: é, à, è, ù, â, ê, î, ô, û, ë, ï, ü, ç, and very rarely used ñ and ÿ.


German: ä, ö, ü, ß.


Hungarian: á, é, í, ó, ú, ö, ü, ő, ű.


Italian: à, è, é, ì, í, î, ò, ó, ù, ú.


Norwegian: é, è, ê, ó, ò, â, ô, å, æ, ø.


Polish: ć, ń, ó, ś, ź, ł, ż, ą, ę


Portuguese: á, â, ã, à, é, ê, í, ó, ô, õ, ú.


Spanish: á, é, í, ó, ú, ñ.


Swedish: å, ä, ö.


Turkish: â, î, û, ö, ü, ç, ğ, I, İ, ş.

I would love the Pyra could do Portuguese.

 

[Grench]

Here is a layout with the punctuation you need for natural language all on the left:

http://www.keyboard-layout-editor.com/#/layouts/fb9f7d7dbe0e66f38f70fd7a01896878

(I also made the keys a bit thinner so they have a more realistic aspect ratio)

Features:

• , . ' " ; : / ?  all on the left, so you can easily input natural language without using shoulder Meta.
• - is a Meta-mash combo
• the ÜÖÄ triangle has Ü on U
• ç and ñ on C and N

Disadvantages:

• it looks more like an arbitrary splatter of symbols than some of my other proposals

Here another one, now with the "foreign stuff" clustered in the middle:

http://www.keyboard-layout-editor.com/#/layouts/657a91653495a21fe551349c3ee89ba2

The [] /|\ {} cluster is strategically positioned for the command line: ~/ and ./ are easy combos, for example.

On the right you have ? ; : in their expected US-QWERTY locations and around space, for easy [punctuation space] combos.

I kinda like this one.

Both of these are generations backwards from where we already got to.  Ergonomics, location memory, DosBox/QEMU/other compliance, desktop/dock use are all getting kicked to the curb and run over.

You seem to be making layouts at a rate of 1-2 per day.  Any negative comment from anyone seems to result in a completely different structure to satisfy their request at the sacrifice of every other gain that has been found over the course of this process.  I appreciate brain storming and out-of-the-box thinking, but these recent ones seem to be just a scrambled mess.

Let's get back to actual viable alternatives.  You made several.  You inspired several.

Layouts like this are far more viable:

http://www.keyboard-layout-editor.com/#/layouts/467f092b9169fe6c6b411baa5a39beeb

 

[ible]

perhaps, but I don't think ED wants more than one meta label per key. (see OP.) otherwise he would have chosen a different layout (we had a few at the time with your qualifications). we might even lose another key to a second keyboard shift.

we are spinning our wheels quite a bit, perhaps over nothing. i agree though, that the latest _wb_ lacks some Je ne sais quoi. (he seems to be breaking his own principles.) i like http://www.keyboard-layout-editor.com/#/layouts/fb9f7d7dbe0e66f38f70fd7a01896878though.

it's iterative refinement, sometimes you make a good step, sometimes you make a bad one. i like _wb_'s idea of putting /? together and \| together, though, since those are companions on the US keyboard. Inspired by that, does anybody prefer:

http://www.keyboard-layout-editor.com/#/layouts/81113d4bd6bfadaa66dd9e913025ed7c

over:

http://www.keyboard-layout-editor.com/#/layouts/1417479de73c9231d7e258fd0eb779a4

?

 

[_wb_]

Both of these are generations backwards from where we already got to.  Ergonomics, location memory, DosBox/QEMU/other compliance, desktop/dock use are all getting kicked to the curb and run over.

You seem to be making layouts at a rate of 1-2 per day.  Any negative comment from anyone seems to result in a completely different structure to satisfy their request at the sacrifice of every other gain that has been found over the course of this process.  I appreciate brain storming and out-of-the-box thinking, but these recent ones seem to be just a scrambled mess.

Let's get back to actual viable alternatives.  You made several.  You inspired several.

Layouts like this are far more viable:

http://www.keyboard-layout-editor.com/#/layouts/467f092b9169fe6c6b411baa5a39beeb

So you claim that

http://www.keyboard-layout-editor.com/#/layouts/467f092b9169fe6c6b411baa5a39beeb

is better than

http://www.keyboard-layout-editor.com/#/layouts/80f214b6324b7131ec5e94b5ecdd410e

in terms of "Ergonomics, location memory, DosBox/QEMU/other compliance, desktop/dock use".

Can you elaborate a bit please, because I don't really see much of a difference:

Ergonomics: not having to mash Meta+Shift for {}| seems slightly less ergonomic than having all of them behind only one modifier. Tab at Meta+Space also seems less ergonomic than a dedicated Tab.

Location memory: except for [] /|\ {} ,.<> and Tab there is not much difference in the locations of symbols. I'll admit that having symbols paired up in the US-QWERTY standard way might help people to find the symbol they're looking for. For people who are not used to US-QWERTY (i.e. most of Europe), that argument does not hold though.

DosBox/QEMU/other compliance: I think there is a consensus that this is a non-issue.

Desktop/dock use: I don't really know what you mean by this, but I don't see much of a difference either.

The way I see it, putting _+{}| on Shift+ -=[]\;/ is certainly a viable option, and it has some advantages.

One of those advantages is that it leaves more keys available on the Meta layer. In a sense that is also a disadvantage though, because we don't really have "useful stuff" to put on all those keys. I mean, sure, we can add £ Å Æ Ø ¿ ¡ and extra diacritics, but the amount of extra 'multilingual gain' we get out of that is rather limited, while it does increase the amount of 'clutter'. In terms of "languages per clutter", it is hard to make good use of the extra room.

There are disadvantages too, though. Plus and minus are on different layers. You have to make `~ a dedicated key if you want to use it for diacritics, instead of being able to apply the trick that Shift+`~ are dead grave and tilde. I can even make Shift+slash dead stroke and Shift+minus dead macron. And a keymat with only 2 labels per key is going to look cleaner than one that has 3 labels per key or more.