Qraizer: Мульён примеров можно придумать. Вот был код в ПЗУ. Часть его .bss секций была априори константной. ОЗУ использовалась консервативно, только для данных и стека. Потом решили повысить производительность кода, в связи чем перенести код тоже в ОЗУ. Чуток подправили harness модуль, и бац! секция .bss перестала быть константной.
Или берём наши железки, что к стенду прикручены. Их начальный загрузчик умеет три варианта: принять исполняемый образ прошивки по RS-у, режим разработчика; считать код приложения из флеш в ОЗУ и активировать JTAG, отладочный режим; передать управление прямо на флеш, боевой режим. Режимы управляются перемычками. В боевом режиме ко всему почему арбитр шины отслеживает несанкционированные попытки изменить флеш (речь о высококритичном софте) и генерит процессору критический эксепшн.
Что тут компилятор наоптимизирует? Реализацией поведение не регламентируется, это настоящее UB.
const не является частью характеристики объекта, на то он и модификатор типа, а не часть определения типа. const, как и volatile, может являться частью контракта его интерфейса. У тебя объект может быть самым обычным, но наружу ты его экспортируешь как константный. Или ни разу не видел, как методы классов возвращают константные ссылки на свои изменчивые атрибуты, репрезентуемые обычными полями? Если такая константа приходит тебе обратно от пользователя, ты имеешь полно право снять с него константность, если вдруг приспичило. Стандарт чётко определяет UB только при модификации исходно константных объектов, для того же поля, которые сразу определены в классе как const, например. Для тех же, на кого константность навешана контрактом интерфейса, но константами в точке определения не являются, никакого UB нет.

https://forum.sources.ru/index.php?showtopic=421537&view=findpost&p=3848517