UPDATE: This problem has been fixed in RTM 2.0.
Some time ago, I wrote a short essay on the potential dangers of using code optimisation indiscriminately. Whereas that essay showed an issue that was almost certainly "by design", today's code highlights what is probably a code optimisation bug.
When you run the .NET 1.0/1.1 console application shown below using the default debug configuration (without optimisation), you'll see the expected answer of 7 printed. If you run the same application using the default release configuration (with optimisation), it will print 5. Make sure that you do this without a debugger attached (i.e. using Ctrl-F5), as the VS debugger turns off code optimisation regardless of the build configuration.
The native code involved and the probable reason for this behaviour is discussed in this newsgroup posting - it looks like a JIT compiler bug to me.