> С другой стороны, если приходится значительно менять интерфейс - сложно назвать это "мелкой ошибкой"

Ситуации разные бывают. Представьте, что приложение работает через веб-сервис, а в том обнаружили проблему безопасности, немного изменили АПИ, и из-за этого пришлось поменять интерфейс приложения. Согласен, что ситуация нечастая, но по СемВер она адекватно не разруливается. Идеальная схема версионирования должна предоставлять удобные варианты для наиболее типичных случаев и быть достаточно гибкой, чтобы позволить реализовать почти любой (а в идеале любой) нетипичный случай.

> Заказчик получает доступ к папке с релизами, а там вполне можно добиться вменяемой сортировки версий.

Вменяемую сортировку придётся делать самим и, вероятно, она будет несовместима с СемВер.

> patchlevel(RC1-ubuntu+master.build3455.2fbf9281)

А вот и нет. У вас в одном поле patchlevel сразу несколько величин, влияющих на сравнение и сортировку версий: статус (RC), номер релиза (1 после RC), номер билда (3455). То есть в вашем случае у вас не major.minor.patchlevel, а major.minor.stage.release.build, то есть 5 величин. СемВер позволяет только три.

Я, кажется, понимаю, вы хотите сказать, что сама схема major.minor.patchlevel логична, и под неё, в принципе, можно подогнать любую другую с определёнными допущениями. Но суть СемВера в том, что схема именно такая, как они описывают, а не почти такая же. Ваш пример - это уже не СемВер, и библиотеки, заявляющие поддержку СемВер, с вашим примером работать не будут. И люди, "имеющие опыт" работы с СемВер, тоже не поймут, что есть что. И проблема не в дефисах/плюсах/точках.

> выпускать функционально такой же продукт (но внутренне переработанный!) особого смысла нет, должны быть новые фичи, чтобы пользователь захотел поставить новую версию.

Почему? После 5 лет развития была версия 1.19.6. Автор решил, что добавлять новый функционал лучше в форме плагинов (не с точки зрения пользователя, а с точки зрения реализации и архитектуры приложения), а это будет возможно только после рефакторинга и добавления схемы работы с плагинами. Он переписывает кучу кода, выпускает 2.0.0, и уже на её основе начинает пилить 2.1.0 с новым функционалом в форме плагинов. Пользователям, конечно, нет смысла обновляться до 2.0.0, но автору такой подход может быть проще, чем сразу писать плагины и в качестве 2.0.0 выкладывать версию уже с новым функционалом.