I'm not going to disagree with your comments on WinForms/WPF or current limitations for WinRT. Let me focus on WinForms/WPF for a minute...
First, I'm curious if your client application needs to support Windows 7? If so, the choice is clear for a Windows platform, WPF. If is the technology that is alive and staffed by the same team building future investments into the Windows client platform.
I was a bit surprised to read this. I do recall this: http://www.zdnet.com/blog/microsoft/microsoft-splits-up-its-xaml-team-whats-the-fallout/9807 which suggests there are multiple teams doing something with xaml, but I learn from your email that this isn't the case?
On the WPF front I contstantly hear that 'there are no new investments' which is fair that there hasn't been significant features in the past release, however we have been doing a lot of bug fixing.
I would like to ask you what you feel has to be implemented in WPF as a key investment? Better phrased: If we had a message at Build, what would we need to say to give you confidence.
Two weeks ago, I wrote a large blogpost: "Microsoft and developer trust (or lack thereof)": http://weblogs.asp.net/fbouma/archive/2014/01/23/microsoft-and-developer-trust-or-lack-thereof.aspx which in detail describes what I think is the core problem.
In short, it comes down to this: how high are the risks when taking a dependency on a technology provided by Microsoft? In the light of WPF vs. WinRT, it looks like Microsoft is pushing towards WinRT as the future and not WPF. I mention both as they're not the same, they use different technologies and even if their xaml looks similar, the code in your app, the expected behavior, it differs at points.
If I add everything up, I see two frameworks: WPF and WinRT. One which gets little to no airtime (WPF) and one which gets all the airtime (WinRT). Both work with xaml, but the xaml isn't interchangeable, nor is the code in the app. In short: two frameworks which do the same thing. If I reason about what could be the future of WinRT, I can only conclude that WinRT will be the next framework to use: Microsoft will add windowed WinRT (guessing here, but it looks reasonable) functionality and this opens the road to use it as a UI for desktop apps without the necessity to use full screen functionality. This also makes WPF obsolete.
The downside is that WinRT isn't a framework one can use with the full .NET framework: you have to use the WinRT specific .NET parts.
So this opens a dillema: Microsoft is heavily pushing WinRT to make sure there are a lot of windows store apps created and by the looks of it, it might very well be this is the future for windows applications, but as it's a limited platform still, it's not usable for desktop applications like one can create with the full .NET framework and WPF, however why would Microsoft keep WPF around if WinRT and its .NET subset grows to a size where one could create desktop applications with it like we do now with WPF? There's then no need to do so, which immediately means WPF is on the track to becoming obsolete.
This doesn't have to be bad, but as I described in my post: it is a risk when one takes a dependency on WPF today.
So for me Microsoft has to make a decision: what will it be: WinRT + its own .NET subset OR WPF and .NET.
IMHO, the best way to solve this is to make WPF and WinRT (from the .NET point of view) equal: so create a WPF application and it uses WinRT as then they're interchangeable (as they both use xaml and .net). this isn't easy and it might not be possible at all, however there is a core problem today: do I trust Microsoft enough that the dependency on WPF is of low-risk?
I don't mean with low-risk / high risk that Microsoft kills off a framework, but that it is a framework in which Microsoft invests and which is a first class citizen. Winforms still runs on windows 8, and there are still people fixing bugs, but there's no core team which owns it and which has made it its future. With WPF, you say there is, however the communication towards customers has been completely unclear about this: the team owning WPF and who has made it its future, is that the exact same team who develop WinRT or not? If so, how does this team see the future of both frameworks, i.e. what happens when WinRT + .NET is big enough to use for LoB desktop apps, currently the domain of WPF? Is WPF always the framework for desktop apps and WinRT only for tablet apps?
Sorry for the rambling, but I hope the point I tried to make is clear: there are currently two frameworks, WPF and WinRT, and if WinRT grows in features, it will compete with WPF on the desktop, which makes WPF not a technology with a rich future and therefore a dependency on WPF will not be of low risk.
Too often we hear vague comments about 'no feature investment' but nobody has anything they can pinpoint to what would be valuable as a feature. This really helps turn this feedback into actionable planning. We can do more with our future-investing platforms (aka WPF on Win8) and we would have to make really tough trade-off decisions for the future when we choose to do anything down-level (Win7). That said it isn't out of the question, just a matter of feasibility and business goals.
I think most people simply want to have assurance that WPF doesn't follow the same route as Winforms when a competing framework surpasses it. When WPF was released, Winforms' days were numbered. It still works, you can still buy controls, but from MS, there's no future in it. With WinRT we see the same thing happening but now to WPF. Or at least, that could be happening, but we simply don't know: it's unclear, which makes people uneasy and the uncertainty coupled with the lack of communication from Microsoft about this makes people draw conclusions whether or not the platform still has a future for them.
I don't think it's about feature x or feature y in detail, it's more about the knowledge they have about WPFs behavior, classes, features and whether they can leverage that knowledge or not in the near future when its successor gains steam.
Now, on the WinRT side of things, I'm well aware of the gaps for the platform in missing features/functionality. I think what you'll see from us is a quick closing of those gaps and in new ways based on the learnings of many years and apps. For example, we may choose to re-think data binding to UI elements due to our learning of how the most high-performing/profile apps use our platform.
If Microsoft could simply get rid of the separate .net framework for WinRT and be able to use the full .net stack for these apps, so i.o.w. 'windows store' UIs is just another UI framework on top of .NET, like WPF and winforms are too, it would be the best solution. I never understood why there's a separate .NET framework for WinRT as .NET is a VM, in theory it can run on any hardware and OS.
It would assure people their skills and knowledge won't get obsolete, the horizon will be extended even. However it currently looks like we're on an island called 'Full .NET' and the ferry service to the main land will soon close as it will continue its service to another island called 'WinRT', so it's key to take the last ferry or get stuck on the island.