в плане?

Ну в том, что стандартная иерархия в точности может соответствовать коммитам:
V1 <- V2 <- V3
caa3 <- bcbd <- 324b

для более сложного графа коммитов можно тоже натянуть (опять же скаловскую) mixin composition. Правда закончится это тем, что код будет выглядеть как макароны по-флотски.
Нужен будет механизм "склейки" объектов из старых версий. Здесь соглашусь, никакой автоматизации никто ещё не придумал.

Вообще задача похожа на фиче тогллы, и на практике приходится напрягаться, чтобы реализовать их, и всегда приходится отталкиваться от того, что за фичи, и насколько долго держать эти тогглы. В противном случае сложность кода возрастает очень быстро.

ну да это всегда превращается в макарошки

вот эта ad-hoc логика версионирования

я поэтому и говорю что было бы круто прикрутить инутицию/дедукцию где это возможно, а где невозможно — сделать first-class интерфейс для описания преобразований между версиями на уровне языка

это же не только для миграций дб полезно

вендоры постоянно меняют API придурки

продавашки

А где мастер не иммутабельный?

Don’t rebase master — это не закон)

историю необходимо переписывать, чтобы она имела больше смысла

Пожалуй, я вырву это из контекста

Разве не закон? Кажись у тебя это банально не получится.. git или гитхаб возможно не даст тебе это сделать. Но это не точно

мастер можно ребейзить сколько хочешь

Если настроить то не даст

Если не настраивать, то даст

Это мягко говоря хуевая практика. Мастер иммутабельный не просто так -- переписывание мастера ломает все ветки к хуйам

В командах за такие выкрутасы кочергой ебут

ломает только если ты ребейзишь точки входа в ветку