In complex clustered deployment scenarios, different nodes in the cluster may be running different versions of their software, which are designed to work with different versions of the database.
In a system where at startup, each node requests the database to be migrated to a given state, nodes on different versions of the software will be in conflict.
To resolve this, if a node requests a migration that was already part of the path that lead to the current state, then it should be possible to ignore that migration. This allows effectively for an "at-least" migration to be performed.
This does not fully solve the problem of having multiple nodes running different versions of the software against a single database - differing expectations around schema still need to be handled - however this is an application design concern rather than a WIldebeest migration concern.