opc.three (8/1/2012)
It's a least common denominator approach. If SSMS were coded to account for every permutation possible to arrive at the most efficient way to add a column think about the design, the testing and the support when new schema features are introduced. Now, all of that said, they have most of the technology worked out to do it and it has been part of Database Projects since VS2008 incl. VS2010 and SSDT for 2012, however afaik Database Projects still do not account for Replication. That is quite a tall task you're expecting. Maybe I missed it, but why even bother with SSMS if you know the issues and know how to work around it?
1) Because I am a production DBA and I have to deal with developers who depend upon tools to generate code, and they have been known to turn this in for a table that is, say, 100 GB and then ask me why it takes so long to add a column or why they are running out of disk space. 2) Because CRM does the same thing on a production DB and there is no other way to update the CRM schema -- and replication is a requirement. And what special technique is there to take an "add column" condition and generate the same ALTER TABLE script that has been standard for over 15 years? You either add it as NULLable or you enforce adding a DEFAULT at the same time you add a NOT NULL column. How many permutations are there to that?
That said, we can't move fast enough to SQL 2012 next year. That is the only bandaid I know of, because most of our replication requirements will no longer use replication. AlwaysOn and read only replicas will do the same thing without the replication requirements.