In WinForms, pretty much all your UI is thread-specific. You have to use [STAThread] so that the common dialogs will work, and you can’t (safely) access a UI element from any thread other than the one that created it. From what I’ve heard, that’s because that’s just how Windows works — window handles are thread-specific.
In WPF, these same restrictions were kept, because ultimately it’s still building on top of the same Windows API, still window handles (though mostly just for top-level windows), etc. In fact, WPF even made things more restrictive, because you can’t even access things like bitmaps across threads.
Now along comes WinRT, a whole new way of accessing Windows — a fresh, clean slate. Are we still stuck with the same old threading restrictions (specifically: only being able to manipulate a UI control from the thread that created it), or have they opened this up?
I would expect it to be the same model – but much easier to use, at least from C# and VB, with the new async handling which lets you write a synchronous-looking method which just uses “await” when it needs to wait for a long-running task to complete before proceeding.
Given the emphasis on making asynchronous code easier to write, it would be surprising for MS to forsake the efficiency of requiring single-threaded access to the UI at the same time.