Java being more widely deployed has to worry about source and binary compatibilities between all the supported versions and thus for them, changing the bytecode would have been a painful decision.

As opposed to that C# did not have to worry about these things due to their limited deploy base and could freely change the language and/or the VM without worrying about backward compatibility.

That does not mean java is a better language than C# - its just that when Sun woke up and started adding features to the language, it was not easy.

Actually it does mean that C# is a better language now. If you are developing new applications then all the compromises that were made to shoe horn in new features don't matter to you. You just want something that works well and is simple. I think that C# has that on Java in a lot of respects.

No arguments there. But the rate at which C# is changing, what is stopping Microsoft from adding yet new features and breaking compatibility with previous language/VMs?

That's why there are generally several different versions of .Net installed side-by side.

That's why they have different releases of the .Net run-time.

I belive that was the original reasoning, and thus led to the Java generics behaving a little weirdly.

Then other decisions forced them to change the bytecode anyway, but they never fixed generics.

I'm not really disagreeing with you - C# is later, has the benefit of Java being in its hindsight.

I don't know how Java does it, but .Net installs framework versions side by side (typically under C:\WINDOWS\Microsoft.NET\Framework) so changes to, say V3.0 don't affect apps that run on framework 2.0 at all. Thus breaking backward compatibility for anyone (small or large installed base, doesn't matter) is not an issue when rolling out a new framework version.