As you mentioned on the related discussion, epochs might be a good fit, since preventing updates to newer snaps without going through a “transition” snap that can handle both user data formats/cases is precisely what epochs were designed for. I know @chipaca was working on epochs support on snapd, if he says it’s ready maybe it would fit your use case better.
In any case, +1 from me, keeping the old release on a compatibility track fits the tracks use case reasonably well and if you decide to use epochs instead, we can always not create the track requested here
The standard practice would be tell users that, if they want to stay on the old snap, they should explicitly switch to track
core16, so they can then migrate at a convenient time for them.
There’s a 7-day waiting period to gather more votes (we need at least two positive votes from reviewers/architects); once the time has elapsed, I’ll check and act as per the state of voting at that time.