Ideas:

1. It seems like many SchemaUpdate subclasses have inherent inverses, e.g., it should be easy to derive a DropTable from a CreateTable. Could we simplify upgrade() and downgrade() into a single function that returns objects that can process both directions of changes?
2. Maybe add a CompoundUpdate or similar that applies multiple updates in a single migration. This might be more complex than it seems though if the migration executor and/or migration status information assume that migrations are atomic.