So, to preserve this 'nifty' behavior, I noticed and preserved a reasonable condition that developers could consider to deliberately allow this: the base key's ID matches that of the subkey, but the layer is different - the subkey highlighted above has layer = 'shift'. So, I turned it into a selection rule - if there's no perfectly-matching subkey, we'll take the first "near-match".

I like the concept but I am concerned that it adds unwarranted complexity to the touch layouts. This kind of 'accidental' feature is difficult to maintain over time and leads to complications, if we want to add more functionality to the OSK. I prefer these kinds of features to be deliberate -- e.g. having an isDefault property on the subkeys (which can be true only for one subkey in any given subkey array). That's more flexible in design and to accommodate. So, can you disable that functionality and we can revisit that in 15.0?

Originally posted by @mcdurdin in #4306 (comment)

So, the core suggestion is the highlighted part above.

That discussion arose because of a classic 'bug' -> 'feature' scenario with subkey support that occurred during 14.0 development. We'd disabled the old phone-targetted base-key prepending operation, but had forgotten to disable the first-subkey auto-selection... which actually turned out to be a very useful feature for some keyboards.

One such keyboard is khmer_angkor, where many keys specify the desktop-layout's shifted version of the key as its initial subkey. The 'shifted' variant sees high-frequency use, so auto-selection can provide a very useful UX shortcut and improve speed of use.