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.