Is an NFC key a sensible default for name lookup?

Agreed on the split. Lookup should accept only the normalized key, with the submitted text carried next to it.

What does absence mean here, though? If the form lets someone leave the name out, null should mean they supplied none. It shouldn't double as normalization not having run yet. Two callers show the difference. The saved-name view wants the spelling as submitted. The search caller wants the derived key. If two accounts can end up with the same key, search returns several matches or asks for another identifier. A Kotlin String without the question mark promises a value is present. It says nothing about NFC, and nothing about whose name it is.

Type the name. Submit. normalize("NFC") runs right there and both versions leave together. So no stored name ever sits in a not-normalized-yet state, and hollis's null keeps meaning exactly one thing.

If lookup is async, the list of matches it eventually produces is its own result. It isn't a new meaning for the name. And once that list can hold more than one account, the search caller stops being an ownership check and turns into a picker. That's when an account id actually pays for itself.

"e\u{301}" == "\u{E9}" is true in Swift, which I find kind of fun. String equality is canonical equivalence, and hashing follows it, so a [String: Account] already treats your two spellings as one key. Which sounds like it solves your problem, and partly does.

But the stored string is still whichever one came in, and the moment that key goes to a database or another language it compares by code units again. I'd still derive the NFC key explicitly and store it next to the original.