And having WebUI access and installing to hardware (or desktop VM that interprets hardware directly).

If you don't use a US keyboard then the keystrokes are interpretted incorrectly when sitting at the hardware, but as your web browser (or any other remote access tool) is running on your local computer (which one would assume is set up to work correctly with your non-US keyboard) then the keystrokes are interpreted correctly and passed (via the internet/network) to your TKL appliance. But obviously they don't correspond to what is stored on your server as it has the wrong information to start with.

So this situation only occurs when you run the machines locally on hardware. If you use AWS/other VPS provider/or virtualisation which uses a Web browser UI then this situation will not occur.

So I guess the workaround for use of TKL on hardware (and desktop VM) is to use a US keyboard for install if possible, or failing that, use standard characters on install that (hopefully) won't be mis-interpreted and then change the password (via SSH terminal, WebShell, Webmin or some other remote means) after install...

The only way to completely fix this would be to detect & confirm the use of US/non-US keyboard on install. That's not a huge deal I guess but seeing as users with non-US keyboards would be a minority, and users installing to hardware & desktop VM; a subset of them, at this point I don't know whether it will be a priority for the core devs. Regardless I think that it is good that this is documented so at least users such as yourself can work out what is going on!

[edit] I edited my original post to include desktop VM as a problematic target. Initially I thought this was limited to hardware install, but on re-reading the thread it seems the OP had this issue with desktop VM  software.

Also: Bug reported here.