The tealeaves of Avalon

Avalon is usually described as the new graphics subsystem for Longhorn, as if it were the successor to GDI and GDI+, but it's clearly a lot more than that. Going by the PDC session list, it's more like a successor to the window manager, common control library and COM automation put together with features from UI frameworks like MFC and Windows Forms thrown in to boot.

So what can we read from the tealeaves-- I mean, session abstracts?

• Avalon (CLI200) is built around a Desktop Composition Engine which means each application thinks it has the desktop drawing surface to itself. I remember one preview of the Nashville shell being described as "Microsoft Window" because documents were hosted directly inside the Explorer shell. I wonder if Avalon will become known as "Microsoft No Windows."
• The key underlying graphics abstraction is Direct3D (CLI340). However, Direct3D is way too complex for most desktop applications, not to mention a pain to migrate existing 2D code, so the API is said to resemble GDI and GDI+ rather than Direct3D. Using the Direct3D engine does mean we get a scaleable desktop, as if we were working on a vector rather than raster surface. Display PostScript, anyone?
• Avalon provides a command framework (CLI351) and "integrated document services" (CLI305). Is this bringing document/view or MVC into the core Windows platform? Or is "integrated document services" simply clunky old data binding (CLI306) given a buzzword makeover?
• There's a UI automation subsystem (CLI307). This will be a gift to help authors, testers and administrators (ARC334) as well as to CBT providers. The automation subsystem will be accessible from a (ahem) "Next Generation" command line (ARC334).
• Speech and pen input are supported for both data and commands (CLI351).
• Design-time support is built into the framework (CLI302). In theory this is true in Windows Forms as well, as the designers are part of the framework not part of the IDE, though in practice the framework doesn't provide any useful host for the designers. What is interesting is that Microsoft talk about building Avalon applications using "markup" (CLI300). I'm increasingly suspicious about trying to define behaviour using declarative markup, so it will be interesting to see how Avalon draws the boundary between markup and code.
• Avalon is component-oriented (CLI301) and supports "deep" integration with the Windows shell (CLI303). Previously it's been hinted that Avalon's component orientation extends to visual and behavioural inheritance, with the implication that Avalon components will be able to inherit from shell components such as Explorer. Which, if true, would be nice -- I certainly find this a lot more tantalising than the prospect of bendy windows.

How all this fits together is of course another matter, and something I'm looking forward to finding out...