Eugene NewСначала делают лишний байт чтобы туда писать ударения. Потом ударения туда не пишут. Маразм?
Отнюдь. Эта возможность здорово выручает, когда нужно, например, снять необязательные диакритические знаки или, наоборот, автоматически расставить ударения, долготы и т.п.

Eugene NewС этим более удобным подходом юникод для ударений оказался не нужен, лишние байты вообще не используются.
«Лишние» байты, как вы и сами знаете, не для ударений, а для расширения репертуара. Стандарт определяет, например, что 045E (белорусское краткое у) будет автоматически разложено на или собрано из 0443 (у) и 0306 (комбинируемый знак бреве). Время от времени такие вещи бывают полезны.

Eugene NewМогли бы и свои любимые иероглифы писать обычным однобайтовым алфавитом в виде слов, разделенных пробелами. Ведь у каждого иероглифа есть название. А сортировка по алфавиту к иероглифам в принципе не применима.
Китайцы вас не поймут, а плюнуть на них не выйдет: их слишком много. Факт наличия — пусть и неалфавитной — сортировки выводится из факта издания бумажных китайско-всяких словарей.

Eugene NewУтвердили бы стандартные написания иероглифов и писали бы:
sunshui vchai maodz une
Такое и без спецсредств прочитать можно, и расшифровать для рисования несложно.
По отношению к китайскому это и есть «спецсредство». И да, вы снова опоздали: пиньин иже изобрели :)

maytonЫ2«Лишние» байты, как вы и сами знаете, не для ударений, а для расширения репертуара. Стандарт определяет, например, что 045E (белорусское краткое у) будет автоматически разложено на или собрано из 0443 (у) и 0306 (комбинируемый знак бреве). Время от времени такие вещи бывают полезны.

А в каких приложениях вы это использовали?
Обработка естественного языка

Eugene NewЫ2,
тут как раз спор и идет, нужен ли второй байт для расширения репертуара или нет. Я вижу в предложенном примере довод в пользу того, что можно обойтись, втиснув стандартную кириллицу в один байт вместе со стандартной латиницей, а для всяких экзотических букв с галочками или точечками использовать запись этой точечки как отдельного символа, что, как оказалось, и так делается - даже с юникодом, потому, что так, оказывается, удобнее! Так что непонятно, в чем профит юникода.
Изначально вы хотели однобайтовости, чтобы обрабатывать строку как массив символов-байтов. А с комбинируемой диакритикой так не выйдет: у вас не сойдется число байт с числом видимых человеком символов.

Вы, похоже, неверно поняли, что я написал. Если несколько длиннее, то Юникод не обязывает вас хранить ранее помянутое белорусское краткое у в виде двух символов (у и бреве), но предписывает, что реализация должна дать вам возможность как разобрать его на эти два символа, так и собрать обратно, если вам потребуется . Иногда бывает нужно разом снять все необязательные долготы, но не всегда заранее известно, как именно пользователь их расставил: использовал комбинируемый знак 0304 макрон или вручную вставил соответствующую по виду букву (0100, 0113 и т.п.) из Latin Extended-A.

Насчет профита… Скачайте стандарт, таблицы символов для различных блоков. Там так много интересного.