R>>Никакого особого преимущества перед UTF-8 в этом отношении нет, если не надо парсить отдельные символы
ЕМ>А если надо? Любая работа с текстами сверх тупого копирования предполагает парсинг отдельных символов и подстрок.

Это да. Но в винде 2 байта эту проблему не решают, потому как юникод в два байта не умещается. Все-равно надо все парсить, чтобы корректно работало.

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

ЕМ>У линуксов те же драйверы файловых систем пути/имена внутри себя тоже обрабатывают в UTF-8?

UTF-8 так устроена, что разделители путей, впрочем и любые символы ASCII, какие требуются для интерпретации команд шелла,
поиска и навигации по папкам, всегда такими и остаются. Расширенные символы всегда мапятся в диапазон за пределами ASCII,
поэтому случайно символы разделения путей и т.п. никак не появляются. Поэтому для программиста это эквивалентно работе с ASCII,
просто часть символов будет означать какое-то название файла или что-то подобное, просто как единый кусок байтов.
Разбивать на отдельные символы этот кусок байтов для работы с файлами не нужно. Да и искать символы точки, чтобы вырезать часть имени файла, можно без надобнсоти разделять байты на отдельные символы.