Entity Framework migrations don't support parallel development

EF migrations borrowed a lot of ideas from Ruby on Rails migrations and this a good thing. The bad thing is that EF treats database as the source of truth. Unpleasant side effect of this approach is that only one developer can work on database changes at a time.
It seems that every time EF creates a DB migration it stores some kind hash of the current database schema which is then used before to the migration is actually executed to make sure that the database is in the right state. This breaks down very quickly when more than 1 developer works on the model. Sample scenario:

1. Dev1 adds migration for a new property called Master  and pushes the change.
2. Dev2 adds migration for AnotherDev property and applies it to the database
3. Dev2 pulls Dev1’s changes
4. Dev2 tries to run the app and gets an exception.
5. Dev2 needs to delete his migration and rollback corresponding changes in the database
6. Dev2 applies Dev1’s migration
7. Dev2 adds again migration for AnotherDev property
8. Dev2 is ready to push his changes unless someone else introduced a new migration in the meantime. In such case Dev2 goes back to step number 4.

I’ve put together a simple app on GitHub that reflects this flow. Each commit is meant to represent a single step.
EF has a chance to become a decent ORM with even better tooling but before this happens EF team needs to understand that developers know what they do and prefer to have more than less rope at their disposal.
I’m happy with the product to be safe by default but there should be a way of disabling those annoying limitations. Without this ability Scott Hanselman idea of LEGO size building blocks is….well just an idea when it comes to EF.