There are a number of changes to the Windows Forms APIs  that are required in order for it to fully support sophisticated marketable applications.

1) Windows Forms must support conditional Focus management.  Tab order is nice but many applications need to control every aspect of focus management.  This is especially true where the application uses focus events to do field-level validation and where the state of a form changes the way it behaves.  Ideally I would like to be able to use a State pattern to control both validation and focus management.  Now I know some of you out there are saying why don't you just set focus where you want it--yes I've heard this before.  The reason this doesn't work is that once focus is given to the wrong control and then it is given to the right control, the validation machinery on the wong control will be invoked.  This creates all sorts of cross dependencies, and makes the form tightly bound to its state.

2) Factor the Controller logic from the Viewer logic.  Model-View-Controller may not work in modern windowing systems in their purest form, but there are still many advantages that can be reaped from factoring the View and Controller.  Even if there is still a one-to-one relationship between the view and the controller in terms of object instances, by factoring the controller you make it possible for a client developer to completely replace the behaviour of a control, without creating a subclass for every control.  With generics being added to C# you can still provide backward compatiblity.  For example:

public class TextBox
{
   ...
}

public class UiTextBox<controller> : where controller : IController
{
   public class UiTextBox() {
       m_controller = new controller(this);
   }

   protected override void OnXXXX(...)  {
       m_controller.OnXXXX(....)
   }

   private controller m_controller;
}

public class MaskedTextBox : UiTextBox<MaskedController>
{
   ...
}

In this way the current library structure could be supported while increasing the power of the library.  What you end up with is a Bridge pattern, where the richness of the bridge interface could be increased as needed.

3) Open it up.  There are many places where Windows Forms is not sufficiently extensible.  I think just about every developer that is writing a Windows Forms based application with the intention of selling it is either using the Menus from the Magic library, or Menus from some other library to give that same richness of expericene that MS Office has gotten end-users to come to expect. Yet in the Control class, the ContextMenu property is still based on the old Win32 style menus.  The same is true for Form.Menu.

Well, I'm getting tired of writing, and you're probably tired of reading.

Thanks, for reading this far.
Wells