Actually, there was a small discussion about that on Joe Bedas blog sometime ago.
The gist: DCE doesn't exist anymore, it's been merged with the application layer compositor and is called UCE (universal composition engine). The DWM will thus use the same compositor as the Avalon application. And furthermore, the UCE _is_ part of Avalon.
So Aero (Glass) requires Avalon in one way or another.
BUT... the UCE can run in software mode. So it'll be likely that the WindowsXP build of Avalon will run in software mode inside the application, and some lower layer XP specific code will use GDI and User32 for display and input, instead of an desktop UCE on
top of LDDM/D3D and whatever will do the input on Longhorn.
Now regarding WinFS, currently it is built on top of NTFS, but since it currently also supports static folder structures defined inside the store, filesystem semantics are supplied. Thus I see no reason why you wouldn't be able to merge WinFS and NTFS for a
post-Longhorn operating system (WinFS V2). Just drop an additional bitmap into the data file (next to the free page bitmap) that tells the filesystem driver which pages are used for data structures and which for filestreams. I'd rather want to see an unified
filesystem than some piggyback thingymajic on longterm.
It would be hard to make a standard, since XAML is more of a way to map the Avalon API into XML, not a strongly defined markup.
But since we're again at Avalon and XAML, I'm wondering, did the stance about MDI in Avalon change by now? The last thing I knew was that it wasn't planned for 1.0, so developers would have to write their own MDI handler (wouldn't probably be too hard fiddling
with panels, but it's all about getting system window borders and what not).
I can tell you from experience that home users will likely hit OK and ignore any warnings if the application title is pleasing enough, for instance above mentioned exampole "Paris Hilton pictures".
Another question anyway:
Will ClickOnce show warnings if the publisher changed during an update? Because it wouldn't be exactly the bomb when some hacker uploads a different package and ClickOnce assumes it automatically safe because the update comes from the same place as the initial
install and all previous updates.
The problem with listing repro steps is that internally they're using newer builds than us beta testers. And I've seen it a couple of times in the Office 2003 beta that my repro steps didn't work for the developers, because changes in the newer builds
changed the way slightly to reproduce it, so I had a bunch of bugs that had to be reopened after a beta refresh.
So depending on what's reported, I'd expect the developers to take at least a quick look at the responsible code section, hoping for some "Doh" moment.