OS and app defaults that preinstall a layout reinforce the same path dependence

What it is

The layout a user meets on first boot and first text focus is almost always the one the OS or app preinstalls and sets as default. A default is not a neutral backdrop. It decides which mapping most people automate, what third-party keyboards must match, and which legends hardware vendors print. Each alternative omitted from the preinstall list becomes harder to reach; shipping a layout without making it default is far weaker than “this is what you get at boot.” Path dependence is re-cemented through the distribution channel.

Why it happens

Default layouts occupy three gates. Discovery: optional layouts buried in settings are found mainly by people who already know their names. Startup cost: even when the system supports Dvorak or national variants, first selection means changing system settings and maybe physical caps, which most people will not do on unboxing day. App override: browsers, games, and remote desktops that ignore the system input source and interpret scan codes by their own tables shove a custom mapping back to the factory assumption. Software distribution is steeply skewed—top store IMEs copy the system default rather than challenge it. “Configurable” holds in the documentation; in the population it is still one path.

Studying it

Audit the out-of-box flow: on a new account and locale, which layouts appear on the first screen, and which require searching an internal name. Count steps and admin rights needed to change layout after boot, then how many apps still bind shortcuts to physical scan codes instead of the character map. Separate “the system claims N layouts” from “the share actually set as default.” Locale experiments matter: the same OS preinstalls different lists under en-US and fr-FR, showing that defaulting is a shipping decision, not a technical ceiling. Presence in a settings search is not evidence of adoption.

Where it stops holding

Enterprise images and school lab images can change the default, so the lock is a distribution policy, not a kernel limit. A mobile app that draws its own keyboard can bypass the system layout, though system password fields may still force the default. Accessibility and minority-language layouts are sometimes “suggested” yet still ranked after the default; suggestion is not preinstall. Embedded devices with no settings app have only the preinstall, and path dependence becomes a hard code.

Applying it

• When shipping to a language market, put that market's ordinary layout on the first out-of-box screen, not only in the full list.
• Read characters from the system input source; do not hard-code shortcuts to “whatever sits on the physical Q,” which resets a custom map to the factory assumption.
• If a product offers layouts, place the switch near first text focus rather than in an admin-only policy page.
• Verify with a fresh account: time and count the steps to the target layout, then open the app, a browser, and a remote desktop and confirm all three honor the new map.

Related

• Same group: C6.17.1 QWERTY originally separated keys to avoid typebar jams, not to match modern key actuation · C6.17.2 Keyboards no longer jam, yet layouts stay locked by network effects rather than engineering constraints · C6.17.3 In multi-person collaboration, sharing one layout outweighs individual switching gains
• Adjacent: C6.01 QWERTY and layouts · C6.07 Keyboard types and task fit
• Search: default keyboard layout · preinstalled input method · out-of-box layout