Разумно ли по умолчанию искать имена по ключу NFC?

С разделением соглашусь. Поиск должен принимать только нормализованный ключ, а отправленный текст идёт рядом с ним.

Но что здесь означает отсутствие значения? Если форма позволяет не указывать имя, null должен значить, что имя не ввели. Совмещать с этим смысл «нормализация ещё не выполнена» не стоит. Разницу видно на двух вызывающих. Экрану сохранённого имени нужно написание в том виде, в каком его отправили. Поисковому вызову нужен производный ключ. Если у двух аккаунтов может оказаться один ключ, поиск возвращает несколько совпадений или просит другой идентификатор. String в Kotlin без вопросительного знака обещает только, что значение есть. Ни про NFC, ни про то, чьё это имя, он ничего не говорит.

Вводим имя. Отправляем. normalize("NFC") срабатывает тут же, и обе версии уходят вместе. Значит, сохранённое имя никогда не зависает в состоянии «ещё не нормализовано», и null у hollis сохраняет ровно один смысл.

Если поиск асинхронный, список совпадений, который он когда-нибудь вернёт, остаётся самостоятельным результатом. Нового смысла у имени от него не появляется. А как только в списке может оказаться больше одного аккаунта, поисковый вызов перестаёт быть проверкой владения и превращается в выбор. Вот тогда идентификатор аккаунта и начинает себя окупать.

В Swift "e\u{301}" == "\u{E9}" даёт true, и мне это кажется забавным. Равенство String основано на канонической эквивалентности, и хеширование ему следует, так что [String: Account] уже считает два ваших написания одним ключом. Звучит так, будто проблема решена, и отчасти так и есть.

Но сохранённая строка всё равно та, что пришла, и как только ключ уходит в базу данных или в другой язык, сравнение снова идёт по кодовым единицам. Так что ключ NFC всё равно стоит выводить явно и хранить рядом с оригиналом.