Just another vote for some serious work to be done on Management Studio.

+ like everyone else, I agree it's really, really, really slow and cumbersome

+ right-click madness... not exactly intuitive that sometimes the only way to perform an action is to do your standard tree-node-drilldown, then right-click.  I'm not sure why that's such a cool feature but that it's the ONLY way to do things, is maddening and is killing my carpel-tunnel.

+ window positions and sizes are not retained.   So agai, you have to expend wrist/mouse action to resize  window, but the minute you close it, all is lost.  I would say the same thing applies to  things like certain "settings".  For example, if I want the window refreshed every 20 seconds, that setting should always stick.

All these things seem like nits, but if you have to actually sit at your computer using SSMS for a whole day, they're annoying, frustrating, time-consuming.... all productivity killers.

On another note, from a programmatic perspective....

+ Integration of CLR... well not really.  Sure, you can use .NET code in SQL now.  But the scenario is one of those "what are you thinking?"  So, my dev team has a one or more core classes that they've written that's used by our various web and console apps.  This is great because we can truly control and encapsulate logic.  Now, *in theory*, I can use that code in SQL too, except it's completely disjointed/disconnected.  You have to import the code, and immediately, you've got a branch in the road you have to manage.  So, when the dev team redeploys their DLL, it's NOT done, because now someone has to go update it in SQL too.   Plus you have to do all that footwork to wire it up to SQL functions in addition...

I don't see why SQL should be such a closed environment environment anymore.  Even though I use Visual Studio to create SSIS packages, and SSMS is somewhat of a Visual studio environment itself, the experience couldn't be more foreign and completely unnatural to someone developing in .NET.