Tom Zagotta brings up several good points in his comment.  There are three ideas in particular that Tom brings up that I want to try to address:

1. MS should be clear about the future of MFC.
2. MS should provide better guidance on when to use MFC vs. WinForms.
3. It would be helpful to developers if they knew more about how MS uses these libraries.

Let me first say that I agree on all three fronts.  We need to communicate this stuff better, and when people tell us we aren't doing it we should listen and then fix it.  Let me also add by way of disclaimer that this is a conversation.  I'm not communicating or setting policy here.  I'm giving you my personal perspective on things.  If we need a more formal means of communicating this stuff later we can do that.

The future of MFC
I'm sure many of you read the MSDN article I wrote on this topic.  If not, go ahead.  I'll wait for you.

Okay, ready? Good.

It's true that MFC changes in VS 2005 are modest in comparison to changes in the .NET platform, VS IDE, C++/CLI, C#, ASP.NET, etc.  I think this is likely to be the case going forward.  As I intimate in the article, future work done on MFC is likely to be focused on integrating with new platform features, managed and unmanaged.  I think there will be small improvements made to MFC itself, like ongoing bug fixing, like the security features in 2005,  and like some of the improvements mentioned by Victor Volkman.  While we definitely want owners of MFC code bases to have easy access to the latest and greatest platform features (things like Longhorn APIs and Avalon come to mind), the innovation (dare I use that work this week?) is probably going to happen elsewhere in the tool stack.

Okay, so should I use MFC or WinForms?
Good question.  I wish I had an easy answer, but I don't.  So let me throw out some information that will hopefully at least help a few developers with the decision.  If you know whether you need to go managed or native, then the answer is pretty easy today because WinForms is managed and MFC is native.  However, the answer may not always be this easy, as there has been a little research done internally on the feasibility of porting MFC to .NET.  While I'm on the topic, let me throw the question out there:

Q: Would MFC.NET be useful to you? What, specifically, would be the value for you? Or are you happy with the current native/managed framework dividing lines?

If you're undecided on managed vs. native frameworks, then answering the question obviously requires a deeper look.  Generally speaking, I would default to a decision of WinForms unless there was a specific reason why this would not be possible.  Some of these reasons might include necessity of control over performance characteristics, application startup time, working set size issues, .NET Framework runtime deployment concerns, or maybe a need for extensive OLE document support.  Some reasons I would default to WinForms include the superior design time experience, my preference for working in managed code, my personal affinity for the componentized WinForms framework structure, and the availability of resources on the newer frameworks should I need help.  With all of that said, it's also worth noting that while WinForms is a great windowing framework, MFC is more mature as an application framework.

As a final note here, I think the fact that all of this is so difficult to explain is because a hole has developed in our application framework story.  I think the time is coming due for a new MS framework that blends the rich application features of MFC with the more modern design philosophies of WinForms or even Avalon.  I personally think it would be really cool is if such a framework could also accommodate forms written in MFC, WinForms, Avalon or even straight Win32 API and tie them all into one coherent application architecture.  This is just me mentally riffing, though.  I know there are some framework research projects underway, but I'm haven't yet looked into the directions they're heading.  At any rate, such an effort -- if we did end up going for it -- would probably be at least 18-24 or more months out.

So, what does MS use?
Almost all current Microsoft products are written in VC++.  Very few use MFC.  Some newer projects are being done in C# and C++/CLI.

I don't think it was ever a huge secret that MFC never caught on significantly within Microsoft.  The Office apps would seem to have been the biggest candidates, but each is instead written with its own very specialized framework tailor made for the application.  At any rate, that ship has sailed, and we're unlikely to see new Microsoft projects being written from the ground up in MFC.

Regarding managed code, people often ask me, "What does Office use?" After all, the Office apps represent enormous native C++ code bases, so .NET must be really ready for serious application when the Office team buys into it, right?  Hard to argue with that logic.

If the Word team, or any ISV, asked me when they should use .NET I would tell them this: use it were it makes sense for you.  Don't just jump into .NET and hope for the best; understand where you can get the most value from .NET and use C++/CLI to move in those directions.  The .NET framework has a lot of great features that can help you build better, cooler, more reliable software, faster.  However, that doesn't mean it would make sense to take a large, perfectly functional native code base and migrate it all to .NET just to say it's now managed code.  What would be the value in that? Rather, if you own a substantial native C++ application today, introduce managed code where it makes sense...

Want to use a powerful third party WinForms grid control in your application? Add a WinForm.  Want to handle some XML? .NET has some good classes for that.  Need to do some cryptography? .NET has good classes for that too.  Need to build in application security? .NET is strong in this area as well.

In the case of Office, they are introducing a new .NET-based programmability framework, and they're also using .NET for some of their server-side bits.  Again, adding value with .NET where it makes sense and not rewriting working code just for the sake of rewriting.

Parts of your application may remain native code indefinitely, again mixing in managed code where there is value.  For example, MS SQL Server 2005 - about as performance sensitive an application as it gets - plans to keep the core database in native code.  However, they are exposing a programmability interface that opens the door to any .NET language plugging into the server.

One of the cool things about VC++ 2005 is that it's equally comfortable in native or managed and the interoperability is really smooth.  As a VC++ developer, you're free to use the platform or library that solves the problem best for you.

Hopefully all of this helps shed better light on the whole MFC/WinForms/native/managed picture.