>> Что же касается кодировок - полагаю, через несколько лет дружно съедем на
>> UTF-32, где никакой переменной длины нет - количество текста со временем
>> особо не растёт, в отличие от объёмов памяти, а обрабатывать много
>> удобнее.
> Не съедем, нету переменной длины - зато нету совместимости с ASCII (надо
> в /etc/somesoftware.conf прописать одной из констант значение в национальном алфавите,
> чего будете делать? весь файл в UTF-32 перегонять?), а также проблемы
> с определением LE оно или BE (таскаться с этими дурацкими BOM'ами
> всюду?), что "by design" беспроблемно в UTF-8.

У utf-8 тоже совместимости нет для всего, что больше кода 127 - всё же как-то переехали. И в чём проблема весь файл перегнать, если места не жалко? (а на текст - не жалко, его сущие копейки по сравнению с мультимедиа). Насчёт endianness не скажу - не изучал вопрос, но учитывая, что распределена только малая часть 32-битного пространства, думаю, проблем с эвристикой быть не должно. Что-нибудь вроде "берём 4 байта и смотрим, с какой стороны у них нули". Да и BOM ничуть не более неудобная система, чем требование к текстовому файлу иметь в конце перевод строки. Определённо более удобно, чем перекодировка на вводе/выводе или переменная длина символов при обработке и связанная с ней возросшая сложность алгоритмов.