I thought with the introduction of the .NET Frameworks and WinForms, that we had finally seen the end of an era where multiple APIs proliferated in the windows platform like MFC, VB Runtime, Win32, WFC, CRT, DHTML, and every other runtime of every other non-Microsoft language like Delphi. Although WinForms was still new and not as mature as MFC, there was that feeling that it would reach the polish of MFC and eventually exceed it; and that could happen with Whidbey.
But, then, you know, Microsoft presents us with this new Avalon API set. I don't know which group owns WinForms, but if I were to guess; it seems, as if WinForms was produced by developer division, but the OS division decided that, since they own Windows, they can do more than a wrapper implementation and actually BE object-oriented and can actually EXTEND the feature sets of all these objects, and so they want another crack at a managed Windows API. For years, Windows have been lambasted for it's lack of object orientation. (I could be wrong; Windows could have developed the WinForms API; I know, for instance, the GDI guys built the System.Drawing namespace.)
To be fair, with the dramatic changes that Microsoft already announced in WinHEC, with the long overdue overhaul of both USER and GDI, it makes more sense to build the Avalon library from scratch, rather than base it on the wrapper library that is WinForms.
One thing is different now. The whole world of Windows has become managed, so there is a consistent type system, consistent deployment story, and cross-language interoperabiliy. With this managed world, we may see API support for advanced constructs like generics.
I don't think we are face an all-or-nothing proposition as before. Avalon and WinForms are both managed, so naturally they can coexist with each other. Only one part of the .NET namespace is affected-- System.Windows.Forms; the rest of the .NET framework is shared. Session "Windows Forms: Exploiting Windows “Longhorn” Features from Within Your Application" has this to say:
Learn how Windows Forms and "Avalon" can work together to make awesome applications. See what work the Windows Forms team and "Avalon" are doing to ensure that there is a clear path for preserving and migrating Windows Forms investment in the "Longhorn" space. See examples of Windows Forms hosted in "Avalon" and "Avalon" hosted in Windows Forms, and how to architect your Windows Forms applications to be best prepared for "Avalon" and "Longhorn"!
As for MFC, the PDC does contain a session on Longhorn-MFC integration. If a managed version of MFC is provided in Whidbey, which isn't clear from the roadmap announcement of MFC support of the CLR, integration of MFC with Avalon and WinForms could be more seamless.
Here's my assessment: The traditional Win32 API is dying except for the Kernel, because it's a flat API, which severely limits the sophistication of applications that utilize it. WinForms and MFC will remain important because Avalon apps only run in Longhorn only and, being a 1.0 product, may require another rev to mature. MFC will continue to be enhanced and supported but it's not the company's direction, so it will be in perpetual maintenance mode. WinForms will continue to be enhanced and probably will have a much longer life span than MFC, because it is managed code, easier for company to enhance, and cross-language (More VB/C# users than C++).
The official Microsoft story is coming at PDC.