If you are running version from a stable branch, changes in DB migrations should generally be forbidden as the policy states since those migrations are not likely to be executed again. Downgrading and then upgrading again is extremely risky and I don't think anybody would ever do that.
However, if one is running stable branch X-2 where X is the current development branch, back porting migration fixes could make sense for upgrading to version X-1 if the migration being fixed is in the path between X-2 and X-1.
Therefore I would forbid every fix to migration earlier than X-2 release (there should not be any in theory but neutron has migrations back to folsom). For the path between X-2 and X-1 fixes might be ok. However, rather than amending existing migration is always better to add new migrations - even if it's a matter of enabling a given change for a particular plugin (*). As nova does, the best place for doing that is always immediately before release.
With alembic, we do not need to add placeholders, but just adjust pointers just like you would when inserting an element in a dynamic list.
Salvatore
(*) we are getting rid of this conditional migration logic for juno anyway