Моя мысль состоит в том, что при переделки ANSI проекта в Unicode в случае UTF-16 делается двойная работа - сначала все переводится на UCS-2, а потом, когда обнаруживается, что UCS-2 и UTF-16 это не одно и тоже, начинаются заделываться дырки с surrogate characters. И это если не затрагивать символов вроде ударений и прочих, имеющих культурно/лингвистическое значение.

В случае же с UTF-8 массу усилий, которые в “нормальном” случае тратяться на героическую замену strlen на wstrlen (а по уму - сразу на StringCchLength), можно потратить на искоренение “лингвистисеких” проблем.

В общем, нехорошо маскировать проблему и говорить, что мы, мол, поддерживаем весь Unicode, хотя на самом деле поддерживаются дай бог только европейские языки.

Так что мы имеем два отрицательных момента. Первый состоит в том, что программисту нужно быть много аккуратнее в управлении памятью при добавлении поддержки UTF-8, так как максимальный размер символа может достигать 6-ти байт для UCS-4, 4-х байт для UTF-16 и 3-х байт для Basic Multilingual Plane. В сравнении с этим правила UTF-16 просты до безобразия - 2 байта для Basic Multilingual Plane и 4 байта для азиатских языков.

Второй отрицательный момент в том, что для того, чтобы сделать что-либо полезное с текстом, будь то сортировка или отрисовка - внутри runtime (в широком смысле) все равно нужно будет получить code-point, что для UTF-8 более затратная операция.

Ну и в качестве курьеза, который показывает, что за аргументацией Майкла Каплана возможно стоит нечто большее, чем абстрактные рассуждения. Google для запроса “utf-16 problem” находит 380 000 ссылок, а для “utf-8 problem” - 5 900 000. Разница более чем в 15 раз

Цитата: But to be honest, given that every project I have ever seen that claimed to support UTF-8 failed in the 3/4 byte cases (some even failed in the 2-byte cases!)

А еще нужно учесть, что длина UTF-8 представления символа из UCS-4 может быть до 6 байт (для code points за пределами первых 17 плоскостей, rfc2279).

Некоторые из стандартных Windows функций имеют UTF-8 overload-ы.

Интересно, не знал об этом.

Я не стал переделывать системные вызовы. Везде, где надо, я в мои классы добавляю временную переменную типа CString, а в вызове делаю SomeStr.ToStr(cstr).
Разумеется, это не так удобно, как обертывание всего API, но работает зашибись.
К примеру, я смог использовать xgettext для интернационализации своих программ, что на порядок круче отстоя с интернационализацией ресурсов.
Теперь языки у меня переключаются динамически прямо в запущенной программе, из меню.

Производительность не пострадала - т.е. я не заметил тормозов. Хотя специально не замерял.

Пришла давеча в голову совсем неоригинальная мысль – а почему ещё никто не сдела…