Everyone and his dog seems to have an opinion on the announcement that version 3.0 of the .NET Framework will actually still be version 2.0... but with extra bits stuck on.
From the comments I have read, it seems to me that people are actually OK with this technically - they approve of the tidiness of separating the delivery of new functionality from patching older functionality - but they're a bit concerned about possible confusion in future, when the version numbers of the .NET Framework (a larger conglomeration of assemblies) and the CLR (which lies at the core of the framework) are not in synch. In particular they're wondering what will happen for releases of the Framework beyond version 3 - will it be .NET Framework 3.5 or 4.0 that introduces C# 3.0 and LINQ?
Confusion is likely to arise because, outside of Microsoft, .NET is usually regarded as being one big package. Up until now, this has been a convenient simplification, but it doesn't make it true.
The advice from Brad Abrams is to stick to using the .NET Framework version number - as we have been doing up until now - and don't worry about how that version of the .NET Framework is really made up, and this seems to be good advice. It's certainly what I'll be doing if I can, but I wonder whether the convenient simplification will now turn out to be broken in practice.
Having made this change, I hope Microsoft are developing clear guidelines for future version numbering within .NET. With more potential for confusion, it'll be difficult to make sure the potential isn't realised. However, Brad's point in his earlier post about not wanting to freeze the top level version number just because the CLR isn't changing made most sense to me.