What can't you do on the desktop in Windows 8 (x86) that you could do before? Can you provide some specific information? Otherwise, we're just talking in generalities which means we're getting nowhere fast...

My definition of dead wasn't so much about what it can do now vs. what it could do then, or about what improvements came along last time.  I'm talking about chatter today.  Where is it going?  That talk is dead by all accounts.

There were 17 months between the release of .NET 4.0/C# 4 and the announcement of .NET 4.5/C# 5.  But the async/await bits were announced 6 months after the .NET 4/C# 4 release.  It has been 9 months since .NET 4.5 was released, the longest waiting time for new info on any .NET version (excepting 2.0, when few teams were relying on the platform).

Is Roslyn all we will see in the next iteration?  That was announced back at Build '11.  Will there be a C# 6, or any CLR improvements?  These are the kinds of answers I'm waiting for.  Not knowing, combined with Microsoft's dramatic change in focus, makes me think Microsoft is slowly doing to .NET what it did to Silverlight.

It'll get there. Be patient.

I've believed that for some time.  I'm just starting to lose patience.

I'm not the typical troll on this site.  I'm a real developer wanting answers.  Microsoft PR has a history of gigantic flubs, and I'm hopeful this is just one of them.  But Silverlight developers all over felt the same way.

Don't forget you can build "touch first" applications totally in the desktop realm without ever touching WinRT. Windows wasn't touch friendly in the past not the applications we have the capability to create.  Once they get the rest of the OS touch friendly all will be golden.

Well, if this is going to happen, I want to know.  Will Windows forever be a two-faced creature, or will there be a convergence of the desktop and WinRT?

The desktop isn't very touch-first friendly.  I've created a data entry application that, if designed in WinRT, would work just fine since the UI is moved up whenever the keyboard would otherwise cover it.  But in the desktop, the keyboard covers half the screen, and that half has half of my data entry inputs.  Having the user manually move the onscreen keyboard around once they get to the bottom of a window is bad UX, and redesigning the application so that all data entry inputs are in the top half with the bottom half empty of such controls is silly ugly.