If you're building the kind of app I was building a few years ago, such as semantic graph editors, where a change in one UI element might have effects that propagate to other UI elements in an uncontrolled way, then, yes, the async comm in Windows 8 (the same problem that exists in Javascript, Flex and Silverlight) requires you to have a systematic approach to how information gets into the app.

(One thing I'd definitely note is that the Windows 8 apps like "Photos" and "Mail" are really a joke when you compare them to the Windows 7 era "Windows Live Essentials", which are really competitive -- Windows Live Essentials can handle mail spools on my crappy 2GB shojou netbook that destroy Thunderbird on a 32GB machine. My experience is that async I/O sets an upper limit on the complexity of what you can do)

VLC will have the option of bending their UI to be something that fits the Metro mold easily, so async I/O and comm should not be such a big deal.

Also, there is a port of sqlite to WinRT.

So there's a new API and the new API is async all the way through. The async aspect gets a lot of attention because it's so pervasive, and can require some adapting. But you're right, the limited API can have a larger impact on a porting effort.

BTW, my point about no database API is in reference to the lack of System.Data (ADO.NET). The assumption is that people are expected to consume data through Web services. It's great that SQLite supports WinRT, though. That definitely fills a big need.

Yes

> In addition, there are no database APIs, for example. So it's really a crap shoot about how much difficulty a given project will take to port.

We will do the database APIs, in fact :)