GP's (I think reasonable) point was that typing A on the keyboard of a locked (or worse, sleeping) computer has no reason to be interpreted as "input the letter A into the password field that will be displayed on screen", which is what the original post is assuming it should mean. There's no real reason it should even mean "input the letter A into the first field that comes into focus", which may anyway not be the password (it could be the Username field in certain setups).
Well, you usually see the logged in user’s name and icon on the screen, and presumably you left your own computer there.
And frankly, UX is about finding the little practices that make the experience better — arbitrarily waiting for windows to bring up a prompt is not making me any good, since I know what I want to do. So in my opinion in this very special case, windows is simply doing an incorrect thing — making the common case slow.
> Well, you usually see the logged in user’s name and icon on the screen
I don't have this experience. On Windows (10, at least), normally I see either a black screen (if it's asleep) or a wallpaper, clock, and a message saying 'Press Ctrl + Alt + Delete to unlock.'
> arbitrarily waiting for windows to bring up a prompt
I don't think it's arbitrary. It's doing something - it's calling Winlogon, spinning up disks and reading hibernation data into memory, restarting power to powered down components, probing authentication methods available (eg: fingerprint/card readers), in case of domain joined computers, validating whether the domain is available (which means firing up network interfaces), and if so, whether the user's password has changed, etc.
There are definitely downsides to Microsoft's approach here - as you mention, in a large number of cases, it takes more time to unlock the computer.
However, there are also upsides if you accept that UX is only one consideration when designing a secure log on prompt, and there may be other priorities.
