In theory yeah, but I think it's more complicated than that. NIPs can be updated in place while maintaining backwards compatibility, so that's often ok. Atomic NIPs are obviously ideal, but many kinds of functionality have interdependencies and would be hard to keep separate. That's the scenario where you'd really need a migration path, but those are just so painful. We're going to witness that with NIP 04/44 this year.
Discussion
this kind of interrelation needs to be removed
i dunno how it is in other codebases but there is such a mess of things interconnected but not actually related, that can be separated, and it makes the entire structure brittle
it took me a week of bashing my head against it to finally go "oh yeah, this is why you put one type per package" and then you can actually start at the tips of the branches and replace them with different or better or entirely separate versions without upsetting the whole tree