Simon Sabin has asked for better usability in the SQL Server Agent log viewer: specifically, to allow you to get to job / step properties directly from the history viewer.
Guru Itzik Ben-Gan asks for a more powerful QUALIFY() option to allow filtering on the same kind of query elements that you can currently achieve with ROW_NUMBER(). This one already has over 80 votes!
Chris Howarth points out even more problems with the custom connection coloring feature in SSMS (all the more reason to use Mladen's SSMSToolsPack).
MauriD asks for the ability to include a NOEXPAND hint for CTEs.
And last but not least, user "7gartner" asks for the ability to store tempdb on local storage in a cluster.
When I read the title of this item, I thought, "oh, he must expect that someone with an active batch that is using a #temp table, might be able to continue working in the event of a failover." Which doesn't make sense because their connection would be severed anyway. But when I investigated the body, the want is much more simple than that: allow a system to avoid having to use shared storage for TempDB. This means not using valuable SAN space and using local hard disks, possibly SSDs. A light bulb went on when I saw that, because I know that outfitting SAN-based SSDs at reasonable capacity can get quite expensive, but an SSD dumped into a server – at a capacity to handle the typical sizing requirements of TempDB disks – would be a much more affordable option. (Paul Nielsen just wrote about using tempdb in RAM, and the implication on using this in a cluster resonates again.)