Soma (my boss's boss's boss's boss) recently blogged about how the CLR took a major change to fix Nullable.  There are 2 lessons here.
 
First, this is a lesson in super-stars. Some background: this was a major change done very late in the game. That's very risk because if you accidentally break something, then regressions mean slipping the product. The change to the CLR was done by Vance Morrison who, in my opinion, is one of the most talented developers on the CLR. (There is nobody on the debugger team, nor has there ever been, who is Vance's equal, and it clearly shows in the mistakes that manifest in the debugger's design and implementation. Although we've have/had promising talent, they've lacked Vance's seniority and experience.)  IMO, the big challenge with changes like this is not so much just writing the code; it's making a broad complicated change which affects many subsystems without breaking anything. It's big, it's complicated, and it has to be done right. This is a great example of the value in having super-stars. In order to do something like this, you need one superstar that can get the job done. You could throw 20 morons on the problem and easily screw it up. This is why people like Michael Jordan got paid so much - he was the superstar that could come through in the clutch.  This is a well known principle. Joel on Software blogs about this here.
 (Additional trivia: When Vance was assessing the impact of this change, he asked me if this would affect the debugger. It turns out there is some minor impact, but we decided the cost-benefit didn't justify a fix. The issue is you can directly use the ICorDebug API to construct nullable types that can't normally exist in the runtime. The details are for another blog entry...)
 
Second, this is a lesson in how valuable feedback can be. The push for this nullable change was largely driven by customer feedback.  Likewise, several times I've asked for feedback on my blog (such as how to display generics, general feedback on the ICorDebug API for the next version, and what to do about Cordbg). I can't emphasize how important any feedback I get from such posts is. The feedback I get here goes straight to the front lines of the technical discussions.  For example, I'll be in an argument with somebody and they'll say "our customers want X, not Y", and then I'll go write a blog post asking "Do you want X or Y?" The feedback is then your chance to participate in the discussion.  If I get a lot of feedback, that evidence is directly consumed. If I get little feedback, we figure people don't care.
 In the fate-of-cordbg case in particular, we actually asked Brad Abrams to blog about it because we really wanted a lot of feedback and he has the most popular CLR blog by a large margin. The feedback from Brad's + my blog entries on Cordbg directly contributed to our decision to cut Cordbg and ship Mdbg in the SDK.