I'm not actually intimately familiar with C#. I remember reading about some of the changes between major .NET version (e.g. 2 to 3) which did not maintain backwards compatibility. However, on review, that may have been backwards compatibility of the bytecode rather than the language proper, in which case I am mistaken.
It would be great if somebody who knows one way or the other for sure chimed in.
C#3 adds features not found in C#2 (just as C#2 added features not found in C#1).
However the C# compiler will produce bytecode compatible with the .NET 2.0 runtime from C#3-code. And all C#2 code will compile just fine with the C#3 compiler.
Basically what breaks is trying to shove C#3 code through a C# 2 compiler, and that can hardly be said to surprise anyone.
The part which may be confusing is that unlike Java and the JVM, C# is tied to CLR runtimes, and you can have several installed at the same time.
C#1 was tied to the .NET 1.x runtime. C#2 was tied to the .NET 2.x runtime (which also powered .NET 3.0 and .NET 3.5). C#3 was tied to the .NET 2.x runtime with some extra LInQ DLLs installed (aka .NET 3.5). C#4 (which again adds more features) depends on the .NET 4.x runtime. And all these runtimes can be installed at the same time.
The fact that Microsoft is willing to "leave old runtimes behind" and create new ones when the language features being requested requires it means they can iterate much faster than the Java can, since backwards bytecode compatibility is not required.
I think it is a decision which has worked out largely to their advantage.
It would be great if somebody who knows one way or the other for sure chimed in.