could go something like (just making this off the top of my head):
>
>More control over hash tables
>Features that lead to better nTier designs
>Optimized, lower level file handling classes
>
>Whereas your typical 9 to 5 VB.NET developer's list will look something more like:
>
>An animated paper clip to help me write better code
>Community portal built into the IDE
>Data Access Classes that are simpler to write but result in monolithic designs

Regardless - think about how this would be implemented. This is not an either or feature. These can be generic so they work with either. For 'Wizard' like features they could be integrated into the IDE. For 'language' features into classes accessible from any language.

>As a C# developer, not much. But put yourself in the place of a VB.NET developer who doesn't really care where the language ends and the framework stops. He just wants to bang out an application.

I don't agree. I think it's pretty obvious and no mistaking it. A language provides structure and commands. The framework provides classes. There's a distinct line and I don't expect that to change. If you go that route you end with something like the VFP language, which although we all love it, is what Microsoft and most 'low level' developers have sneered at for the longest time - why should this a kitchen sink language all of a sudden be in resurgence??? That's what the SDK is for...

I guess at this point we need to talk about what a 'custom' language extension would provide. The only useful example I can think of is building in of a Data Manipulation Language that simplifies data access.

Isn't it ironic. VFP has a powerful and VFP developers ask for an object based data access mechanism. .Net only has object based object based data access and wishes for a DML. Upside down world or what???