I have been using Avalon after hours for a while now, and I am quite impressed.  I have yet to use some of the more powerfull features to full advantage, but I would say this is the best UI framework on the planet.  I have worked in a lot of them (SubArctic, Swing, AWT, SWT, Phigs, OpenGL, NeXTStep, OS/X, MacOS, Apollo, Smalltalk, Squeak, etc.).

Avalon has a very uniform and well thought-out design.  The features work together to result in more than the sum of the parts.  The quality of both the result and the implementation are very high.

I look forward to building rich client applications on this framework for the next decade.  And it is not even in beta yet!!  Congratulations to the Avalon team.

Watch out for canvas layouts and Decorators.  While changes to Width/Height made to the Child element of the Decorator will be visible as the Decorator adjusts to size changes of the Child, changes to the Canvas attached properties are NOT reflected in the Decorator.  It would be more uniform in some cases if the Decorator just decorated the element, and took all layout properties from the Child.  I expect the same issue will happen with DockPanel or others.  The layout of the decorated element is dependent on properties set on the Decorator not the Child.

While it is correct behavior as currently designed, it is not exactly the Decorator pattern I would expect.  Decorators should decorate, not override some of the layout and not others.

Unlike many UI frameworks Avalon has a very general design.  In many frameworks like Swing or SWT a Button has text and possibly an Icon, Menus have text, icon, and a key binding, tool bars have icons, and possibly text, etc.  The presentation of an element is tied to what it does, and that is often rigid text and possibly an icon.  In Avalon the content of these elements can be other elements.  I can put a TextBlock or a StackPanel in a button or menu item.  I can create rich content with styles and animations as the presentation for these elements.  The event model for the two is pretty different, which could be unified as well.  Why do menu items have commands that can be enabled/disabled, but buttons do not?  Why do buttons use Click event, when menu items use the command to make something happen?  Just something to think about.  But, the visual unification is a big step ahead of any other framework on the planet.

The documentation on WinFX is still in pretty bad shape.  This is not surprising when the product is not even in beta yet, but still not what I would have preferred.  Unlike most programmers, I write the comments first.  I consider it bad form to turn over any code to a build that does not have full comments.  Those comments help me later when reading the code, and help anyone else that has to do the same.  My usual method of learning a new API like Avalon is to start with the overviews, to get a good high level understanding of the API in general, and any area I am working on in particular.  Then I learn the details of the API as needed by browsing the documentation, class hierarchy, etc.  For Avalon this has not been working out so well.  The class specific documentation is mostly missing any details not generated from the code, and that means no commeints at this stage.  And there are no overviews for the most part.  But, there are some samples.

The one I ran into today is fonts.  The documentation makes it very hard to see where the pieces fit together, but the FontDialog sample does a good job of putting many of the commonly needed pieces together.  All I had to do is read the code, and ignore the documentation.

Not as bad as trying to figure out Fortran code that was writen in swedish with 6 letter variable names that are appreviations of the swidish words, and no comments (a job I had early in my carreer).