О размытости определения "unicode-приложение"

Это перевод On the fuzzy definition of a "Unicode application". Автор: Реймонд Чен.

Комментатор mpz вопрошал, почему IME не может определить, шлёт ли он символы в unicode-приложение или в не-unicode-приложение и создавать соответствующий символ? (перевод поста по ссылке)

Но что такое unicode-приложение? Вообще-то, позвольте мне перевернуть вопрос: что такое не-unicode-приложение?

Предположим, что вы пишите программу, в которой символ (conditional) UNICODE не определён - так что вы думаете, что у вас не-unicode приложение. Но ваше приложение использует элемент управления, предоставляемый другой библиотекой, а её авторы включили UNICODE. Поэтому, контролы, создаваемые этой библиотекой, будут unicode, не так ли? Теперь вы печатаете этот разочаровывающий символ в контрол, созданный этой библиотекой. Должен ли он генерировать U+00A5 или U+005C?

Ответ на этот вопрос потребует телепатии. Если элемент управления берёт этот символ и использует его только внутри себя, то, надо полагать, IME следует генерировать U+00A5. Но если контрол берёт этот символ и возвращает его вашей программе (скажем, этот контрол - просто красивая строка ввода текста), то вы хотите, чтобы IME генерировал бы U+005C. Но как он может это знать? Он не может же делать какой-то анализ кода в библиотеке контрола, чтобы узнать, что она собирается делать с этим символом. Даже люди с доступом к исходникам не всегда могут решить, как этот символ будет использоваться в будущем. В самом деле, если решение основывается на будущих действиях пользователя, то вам нужно применить какое-то ясновидение (и отказ от свободной воли) для получения правильного ответа.

Замечу, что эта вспомогательная библиотека может быть не в виде DLL, а вкомпилирована в ваше приложение - но в этом случае ваше приложение ни ANSI ни Unicode, а помесь этих типов. Части его написаны с Unicode, а части - с ANSI. И что прикажете делать бедному IME?