Feedback on 2.0 (e.g. #9507 #9617) has made me think about what the real intent is behind having columns with default values. Specifically, I think it is likely wrong to assume that the EF model should have a store-generated property just because there is some default on the column. It may well be the cause the the application will always supply a value and so, when using EF, the default is never used. The default may instead be there because:

• It was needed when adding a new column (either by Migrations or manually)
• It is there for legacy reasons--old/non-EF app made use of it in hand-crafted SQL, but EF never will
• It's just part of the way all columns are created by the DBA or similar--the column gets a default regardless of whether it is needed or not

Going beyond the most general case, if the CLR default would generate the same value as the database default, then having EF do store generation is a no-op anyway. If an app was relying on this for bools in 1.1, and we now generate nullable bools, everything will still work, but the app needs to be updated to use nullable bools.