I just wish it was done in C#
)
Each time I see this sentiment I have to disagree. As someone who prefers C# over VB for a host of reasons, I'm baffled when people want a C# DNN version. Read the quite valid reasons given in the sticky 'where's the c# version' thread as to why supporting two versions would be a nightmare with little benefit.
If you like C# there is nothing stopping you from using it in your DNN install. You shouldn't be modifying core code - and any enhancements you make to DNN should be done through either Modules, Providers or HttpModules. Each of these can be written in C# and used without issue. Personally I write all my DNN code in C# and have never encountered a problem. It all gets compiled down to the same IL code anyway, so there's no advantage at all to having the core in C#. In addition, VB is very readable for learning programmers, at the expense of annyoing more seasoned developers with it's verboseness and occasional syntax ambiguity. If one of the aims of DNN is to introduce an advanced web platform to a less-than-experienced users, then you could successfully argue that VB is the correct language choice.
The only time I ever have to look at VB is if I need to understand what is going on in the Core code to solve a problem or just 'get' what is going on. That would represent about 1% of my total code-facing time with DNN.
And onto the topic of the OP - for me the direction the core is taking with 5.0 is the right one. There aren't enough people and resources on the core team to cater for every whim in end-user demand. However, if they setup the platform to allow for greater freedom of skinning and development, the rest of the community can get to work in developing the kinds of things that people want - whether released for free or as commercial modules. All successful platforms ensure that developers for that platform have all the tools necessary to do and create what they want. I would say that is more important than glitzy UI features - because you can always build UI bits and pieces, but it's much harder to re-engineer a platform to position it for future capabilities.