I heard through the grapevine that there has been some kind of cosmic merging of the VB and C# teams. This is a good thing. There is no credible reason at this point not to have similar capabilities in VB and C#. For the most part .NET development is about syntax and the .NET framework. VB development should not imply limited features and capabilities no matter how individual developers choose to develop in a language.

Evidence that a more sane approach is being taken internal is the correction in Visual Studio/VB 2010 of some absent features. VB Lambda expressions now support sub-Lambdas that don't return a value that can be assigned to the generic delegate Action(Of T)-and automatic properties.

Many times programmers use properties because using properties instead of fields is considered a best practice, and things like grid controls use reflection to bind to properties not fields. The drawback was that most properties simply returned or set the value of the backing field. That is, the property getters and setters didn't have logic in them. With an automatic property:

Public Property Foo As String

The getters, setters, and backing fields are implied. If you use an automatic property it saves some typing. If you use a metaprogramming tool like CodeRush -- which makes code generation much faster -- then an automatic property still eliminates the need to read do-nothing properties. When you use an automatic property just refer to the property both internally and externally instead of the non-present backing field and you are all set.

VB should not mean a limited language. Equity with C# is just fair, and thankfully someone at Microsoft seems to agree with this assertion. To borrow from Alan Cooper, "maybe the inmates aren't totally in charge of the asylum".

VB should have feature equity comparable to C#. Programming with VB or C# should be about syntax preference not access to features. Finally, a more reasoned approach from Microsft for VB developers.