The "flatness" of the new user interface makes it impossible to look at the screen and know exactly what is a splitter bar. They simply blend in with the rest of the interface. The only way to find a splitter bar is to move the mouse around until the pointer changes.

I am constantly resizing my splitter panels to go between viewing code and viewing stack traces, errors, and other output messages. Having to "find" the splitter each time slows me down so this is a productivity issue more than an eye candy issue.

In summary, please paint the splitter bars in a way that makes them stand out from the neighboring windows.

Covariance/contravariance has its beginning in CLR 2.0 and also with the introduction of generics in .NET 2.0 (also in F#, C# and VB)

Then in C# 4.0 and VB 10, we have covariance/contravariance supports in the language itself. Currently we don't have support for these covariance and contravariance in F#.

I know it is a runtime feature of CLR 2.0 and 4.0 and I don't want to play catch up with C# and VB.

But this covariance/contravariance support in C# and VB are powerful to use and also have proven to provide cleaner and clearer ways to understand the code and variances in the types, especially when using parameterized generic types.

This is not the same as this feedback:
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2363794-ocaml-like-variance-annotations-a-and-a-

but we can use that OCaml syntax as well for starter.

This feature should also be constrained to only use covariance/contravariance in interfaces and delegates just like in C# and VB, but F# may provide more supports for other types such as events.
An example of this is the way F# has provided the capability to create extensions to properties and methods, not just methods only in C# and VB.

Expressions Trees are immutable objects, which makes them excelent in many caching scenarios, except for one big detail: They don't implement Equals or GetHashCode().
Considering the fact that they are immutable, I think it will be great if they implemented such methods, so they can easily be used as dictionary keys (for example).

Also, this is more compiler specific, but I think that Expressions generated inside a method, without any reference to local variables, should be implemented as static readonly, always returning the same instance instead of generating a new instance each time. After all, the expression is immutable, so there is no risk of threading issues.

Please enhance or create a new toolbar editor for Visual C++ that is on par with the one available in C#. It seems insane to have to still edit bitmaps outside of Visual Studio in order to get 24 bit colored buttons. I want to easily add buttons and set their bitmaps from a file of my choice just like I do with toolbars and image lists in C#.

Also, I think there is a bug in the current Visual C++ toolbar editor in VS2012 Update 2. If I right click on a button in the current editor and select delete, the button turns black and a new button is created. So, instead of deleting a button, I end up with an extra one PLUS one with a black bitmap! Clearly, the toolbar editor is not getting the attention that it needs.