Rendben, megpróbálom.
Ahol jellemzően előfordul visszafelé kompatibilitási kérdés, ott alapvetően egyetértek a semver-féle verziókezeléssel (általában library-k).
Ahol viszont soha nem fordul elő (lehetnek library-k is, de főleg alkalmazások), ott semmi értelmét nem látom, hogy 1.0-tól 1.2578.x-ig menjen a verziószámozás, semmi információt nem hordoz a fő verziószám, holott hordozhatna más szemszögből.
Erre írtam példaként, hogy ilyen esetben az 1.12.x és 1.15.x között annyit tudsz meg, hogy visszafelé kompatibilitási probléma nem történt és pár új funkció került a programba. Ha viszont más megközelítés szerint képeznék a verziószámot, ha pl. teljesen átalakult az UI és/vagy a fájl formátuma megváltozott visszafelé kompatibilis módon, sőt úgy változott, hogy a régi is tudja olvasni az új formátumot, de az újdonságokat nem tudja megjeleníteni, akkor ilyenkor növelnék a fő verziószámot, pl. 1.12.x-ről 2.0.0-ra. Ilyenkor a verziószámból eldönthető, hogy nem akarok az új verzióra frissíteni, mert a dolgozóimat át kellene képeznem az új menü miatt (pl. ribbon menü került a klasszikus helyére), vagy a régi programjaimban bizonyos információk "elvesznek" (nem fognak látszani), mert az új fájlformátumból nem tudja a régi az újdonságokat megjeleníteni.
Illetve, ha úgy döntenék, hogy átlépek az új verzióra, mert a dolgozóimat már átképeztem, illetve mindenhol tudok új programra váltani, akkor a 2.2.x-ből (vagy 2.0.15) tudom azt, hogy kellően stabil az új verzió, nagy problémát vélhetően nem fog okozni az átállás.
"Azzal meg mélységesen nem tudok egyetérteni, ha kétféle verziószámozást is alkalmaznak egy terméknél (ún. technikai, marketing)"
Itt pedig nem arra gondolok, amikor egy könnyen megjegyezhető nevet adnak egy fő verziónak, hanem arra, amikor ténylegesen más verzió SZÁMot kap, pl. 6.2 - 8.1.