Trade-offs

Yes, that does mean that attackers don't have to guess whether your password uses combining or precomposed diacritical marks (assuming arguendo that your password even has diacritical marks to begin with), but that is at most a few extra bits of entropy on top of a (hopefully) much stronger password. You should not be depending on the lack of normalization for password entropy.

You might also worry that this will somehow break in a future version of Unicode, but it is actually pretty safe. The Unicode stability policy provides that, when a string contains only code points defined in version X of Unicode (for reasonably recent X), the normalization of that string according to Unicode version X will be identical to the normalization in version Y >= X. In plain English: The normalization form is not allowed to change, provided that all of the characters in the input string are mapped in the version of Unicode that you used to normalize it.

This does, however, imply that you need to scan the input string for invalid or unmapped code points, and reject them. This is far less restrictive than most password input boxes, because it still accepts every real character that anyone could use for any serious purpose, including private use characters (so we even support the people who insist on using Klingon etc. despite Unicode having rejected it multiple decades ago). Given the relative lack of stability in third-party private use standards (i.e. different organizations have proposed different private use code points for substantially or exactly identical characters), I think we would be within our rights to reject those, but it's more debatable.

I'm sure somebody will now reply and say that a key derivation function (or password hasher) should just accept raw blobs of bytes and not care about any of this Unicode nonsense. That is correct, such a function should accept arbitrary bytes and totally ignore Unicode. The above comment is not about the KDF. It is about the UI that sits in front of the KDF. That UI has to consistently turn the same text into the same bytes, or else users will get locked out of their accounts. This is exactly the same problem as "make sure the password is always UTF-8, or some other specific fixed encoding," just at a slightly higher level of abstraction.

If it's at least 1280x800? Chuck the 16x32 font at it. Always. 8x16 fonts were from the 640x400 days, not even 640x480. And the 4x6 kernel font was added to handle early low-res 320x200 and similar micro-screens.

I don't want my letters to be 4x6 pixels just because I'm on a cheap hotel 40" 720p TV for the night and it tries to pick the font closest to 12 points tall.

If I've got the pixel budget for large, readable fonts the text console should use it as long as I get at least 80x25, or some other tunable if Linux decides a larger console is the minimum now.

Trying to match to a specific physical size is a printing/publishing issue and only tangentially a window-manager one, not a text console one. If anything I'm constantly fighting the "fixed physical size" attempts because they result in blurry webpages and other things from trying to force-rescale bitmaps by single digit percentages.