That's the question many developers have been scratching their heads trying to determine with the introduction of the System.Nullable data type in the 2.0 runtime. In an attempt to have null be null no matter if using value or object types, Microsoft has made a late design change to the CLR runtime. Changing the runtime a few months before ship date for sometime that has such a high impact like the CLR, should give you some indication how pervasive this problem would be if lefted in its current state.
One of the issues has to do with how null values are handle when boxed. For example, if int x is assign the value of null and object y is assigned the value of x (causing a boxing operation), then one would expect the following statement to be true y == null. However, that's not the case and things only get more complicated with the use of generics.
So big props to Microsoft for the commitment to clear up this problem before VS 2005 ships in November and doing away with all the work arounds and less-than-elegant solutions proposed to developers in previous discussions.