As the latest CTP shows, we are cranking along on WPF.  Most of our time is going towards bug fixing and improving performance.  Really important stuff, but not always terribly exciting for you to read about.  <g> But there are few genuine features that my "element services" team helped bring into the June CTP:

Hardware accelerated layered windows -- yup, we've been working on this for quite awhile, it only took three of our best developers!  But I do need to throw in two caveats:

• Windows Vista will support hardware accelerated layered windows, but we're not sure about Windows XP.  We thought we had it working completely, and in June CTP hardware acceleration is supported on all operating systems.  But after we released the June CTP we found some serious problems on XP.  We're currently trying to figure out if we can fix them without changing DirectX, which is obviously a problem on XP.  So while Vista is safe, it's possible we'll need to pull support for layered window acceleration on XP, I'll let you know as we know more.
• Even with acceleration, layered windows aren't free, because we need to do more coordination with GDI than an opaque window. But it's still a whole lot faster than software rendering. I haven't done a lot of measurement, but ballpark is that if an opaque accelerated window is 10 times faster than software, an accelerated layered window is five times faster than software.

Window.AllowsTransparency -- now you can create a layered window without using pinvoke, check out <http://laurenlavoie.com/avalon/162>

Xaml line numbers at runtime -- If you have a legal xaml, and it's the sort of error that gets caught at runtime rather than compile time, WPF wouldn't tell you the line number -- because xaml line numbers were thrown away after the compilation was done.  Until now, that is.  It's not on by default, because we didn't want to bloat your executable size, but if you put the following in your project file, you'll get line numbers at runtime.

<!-- under the <PropertyGroup> tag -->
<XamlDebuggingInformation>true</XamlDebuggingInformation>

GetValueSource -- ever wonder where a property got its value from?  Try this:

ValueSource s = DependencyPropertyHelper.GetValueSource(button, Button.ForegroundProperty);

That will tell you the category where the value came from, eg:

    public enum BaseValueSource
    {
        Default = 1,
        Inherited = 2,
        DefaultStyle = 3,
        DefaultStyleTrigger = 4,
        Style = 5,
        TemplateTrigger = 6,
        StyleTrigger = 7,
        ImplicitStyleReference = 8,
        ParentTemplate = 9,
        ParentTemplateTrigger = 10,
        Local = 11,
        ElementStoryboards = 12,
    }

(There's also flags for expression, animation, and coercion, which are really orthogonal steps in the property value calculation)

This is intended only as a debugging aid, please don't make your program logic conditional on this.  Please don't write a control that treats 5 differently if that 5 came from a style rather than the default value, that will confuse your users, and your code will break in future versions of WPF as we add more things to that enum.