> The Czech layout isn't exactly an obscure edge case.
From what I understand, the problem wasn't with typing characters actually used in the Czech language such as á, ř or ů. The problem was with typing the ˇ character by itself, which is normally encoded in Unicode as U+02C7 (CARON), but there also is a combining version (U+030C, COMBINING CARON), which is what gets printed if there is no precomposed character (e.g. š is both U+0161 and U+0073 U+030C). There is a thing called Unicode normalization that makes "identically looking" strings actually use the same codes, so maybe it was that thing that changed a bit (maybe even somewhere else and not in the lockscreen/keyboard logic), or they could have just removed the ability to type ˇ by itself altogether since it's not something actually used in any language or writing style and most often comes up as a result of a typo.
I remember a website that silently removed everything but the first 8 characters from the "password" field upon registration but somehow didn't do the same on the login page. It took me several hours and several password resets to actually log in after registration, since for some reason the trimming happened client-side and only when typing the password manually (and I was pasting my password from a password manager).
In a similar vein, I remember encountering a site where the frontend enforced basic complexity requirements ala “use at least one number and one symbol” but the system would silently drop all non-alphanumerics when it saved (presumably in some kind of failed conversion on the way into the backend DB). So setting a password like “foo_bar4!” would become “foobar4” which was surprising. What blew my mind though was when I figured out the stripped password worked to log in, which was how I eventually figured out what was happening, escaped the reset flow, and generated a compliant password.
Tangentially related, a relative bought a new Apple laptop a few weeks ago, and I was tasked with setting it up. The computer came pre-equipped with a Czech keyboard (apparently the US models weren't in stock and that relative needed a new computer as soon as possible, so they bought a Czech one).
Since the user doesn't speak Czech, I promptly removed the Czech layout and installed two other layouts, US English and Hebrew, for the languages that the relative uses to type on the computer.
For some reason, login screen just after boot still uses Czech layout, which means Z and Y are swapped and numbers must be typed with Shift (just pressing numbers outputs Czech letters like ěščř). So when booting up the machine (remember that you can't use fingerprint during first unlock), the user must type the password in whatever layout is physically printed on the keys, even though the rest of the OS doesn't even have a mention of that layout. Somehow afterwards the OS "can" see the list of the layouts and lock screen correctly chooses the English US layout.
Alongside of that, for some reason, the key that's supposed to type ` and ~ in the US layout types some nonsense instead (a plus-minus sign and a section sign), whereas the backtick key is for some reason located between left Shift and Z (good luck unlearning years of muscle memory typing ~/Documents in the terminal)
This feels like it's probably a stupid oversight chain like, keyboard layouts are user-specific data, so they're not decrypted before first unlock/set globally because the machine might have multiple users with different keyboard layouts.
Even if it is, why is there no way to change the system-wide settings? All other operating systems that I know either have an explicit button "Apply settings to login screen" or do it automatically (I'm sure 99% of the consumer-level computers sold worldwide never have more than one user on them, moreso with different keyboard layouts).
Evidently you can, though in traditional macOS fashion, you exploit Apple secretly changing the setting for you if you do a magic dance.[1][2]
I've never had a reason to try it, but there's also a remark that 99% of the Macs sold probably don't need to change the system-wide keyboard layout defaults, either...
Interesting how you need a separate app to open parcel lockers in Poland. In the Czech Republic the locker provider just sends you an email/SMS (as a part of the "ready for collection" message) with a code that you type on the locker's keyboard, which is sometimes physical, sometimes a touch screen, and the locker opens, no app needed.
Note that many European countries have already got rid of their 3G networks completely [0]. So it's either "you have 4G/5G" or "the internet is pretty much unusable", nothing in between.
As someone living in a European country with no 3G network, my experience with mobile data is that when my phone fails to find a 4G signal and switches to 2G (pretty much only happens in remote areas, thankfully), I can as well send my packets using a pigeon carrier, they're going to arrive to the destination sooner.
I flew with RyanAir once after the rules changed, did online check-in on a computer, at the check-in desk at the airport got a paper boarding pass for free, just had to pretend that my phone died and that I have no charger with me.
From what I understand, the problem wasn't with typing characters actually used in the Czech language such as á, ř or ů. The problem was with typing the ˇ character by itself, which is normally encoded in Unicode as U+02C7 (CARON), but there also is a combining version (U+030C, COMBINING CARON), which is what gets printed if there is no precomposed character (e.g. š is both U+0161 and U+0073 U+030C). There is a thing called Unicode normalization that makes "identically looking" strings actually use the same codes, so maybe it was that thing that changed a bit (maybe even somewhere else and not in the lockscreen/keyboard logic), or they could have just removed the ability to type ˇ by itself altogether since it's not something actually used in any language or writing style and most often comes up as a result of a typo.