However, one of them accounts for something like 90% of all the use cases I've ever seen proposed, in any forum, anywhere, for third-party multitasking on the iPhone, and really just boils down to one word: "Pandora". I've said elsewhere and will say again that Apple could probably placate a huge number of people simply by giving Pandora and no other third-party application an exception to the multitasking policy.

But in a larger sense I'm extremely skeptical of the claim that there are many "awesome use-cases that nobody has thought of yet", simply because of the two fundamental problems: form factor and resources.

First, the form factor problem: a mobile phone's screen can only be so large before the device stops fitting in a pocket, which means you get a certain amount of total UI real-estate, and that's it. Unfortunately, it's a pretty tiny slice of real-estate, which means that the traditional multitasking interfaces -- multiple windows, or multiple panes within a larger container -- don't work. You just don't have room on that screen for four or five applications and clear delineations between their screen areas to all be displayed simultaneously; you really don't even have room for two, because even if you cram all your stuff into that space you're still going to run right into Fitts' Law and have something that's unusable.

This means you get only one realistic UI option, which is that every application runs "full-screen". This may not mean using 100% of the screen area, but the size problem means you need to use so much space that there really isn't room for much else to fit alongside it. As a result, all the cool kids in the mobile OS field (iPhone OS, Android and WebOS) are doing the "fullscreen app" paradigm.

And then there's the resource problem, which has been discussed endlessly but not in particularly constructive ways. Every application that's running needs to have code and data resident, and a huge number of them want a network connection too. This means every additional application eats up more memory (a scarce resource on a phone-sized device) and power from running one of the device's radios (ditto -- and note that even if the app someone's interacting with at the moment doesn't need a network connection, odds are that some other running app does, so you don't even get a break when the user's not directly interacting with a network-using app).

This is a resource-management problem, and whatever solution is used for it will inevitably cascade back up into the UI. WebOS uses a card metaphor to cycle between applications, but launch a bunch of applications and the UI goes from responsive to... well, not responsive. Which suggests that, nice as the metaphor might be, it doesn't really work.

The other option, which is the one pretty much everybody else is going with these days, is to have a monitoring process serialize the state of and then terminate one or more applications when resources start running low. This also has the advantage of fitting nicely with the already-necessary fullscreen-app UI because from a UI perspective there's no interaction difference between "Leave App A running, but move App B to the front" and "Save App A's state, terminate it and launch App B". If you don't believe this, note that it's exactly what Android does when it runs low on resources; unless you're watching a process monitor you have no reliable way, as a user, to tell what it actually did when you hopped from App A to App B.

This is also indistinguishable from what the iPhone already does; any decent application already saves state on normal termination, so the fact that the application isn't really running anymore is only noticeable if it was meant to keep doing something in the background (like play music or pop notifications in response to events).

Which means that basic, built-in constraints of running on a mobile-phone-sized device, all by themselves, drastically limit the opportunities for meaningful multitasking. Because of the form-factor problem you can only ever have one application doing actual user interaction at a time, while all others have to sit in the background and do whatever they do without displaying interface (other than notifications) or requiring any serious interaction from the user (basically, you can pop "this thing happened" or "would you like to do X? Yes/No", and not a whole lot else because you don't have room for more UI without stealing full-screen focus, which is, again, indistinguishable from a serialize-and-terminate-and-launch).

Which brings us back, basically, to "play music while some other app is being used", and "pop up notifications". That's not exactly a rich playground of possible use cases; music is, well, music, and notifications are basically only worthwhile to do when:

1. Event X happens (e.g., IM or SMS received).

2. Clock reaches Time X (alarm, reminder).

3. Device arrives at Location X. This offers the largest number of possibilities, but there are still only so many pseudo-geocaching games, walking tours and social-network things you can do without flooding the app market with a bunch of essentially-duplicate applications.

So... yeah, there's really only the two use cases for multitasking: music, and notifications (which I tend to lump under "IM" since that's the one people would probably use the most).

As a side note, what's best for enabling this is not actually full multitasking (in the "every app stays completely resident running all its stuff" sense), but something much more like daemons which periodically wake up and do things.

These apps would at least have a modicum of usefulness, unlike the plethora of movie quote soundboard apps.

But then again there are all kinds of multitasking devices on the market, so nothing is really stopping the innovation of new use-cases. So I guess we do totally agree. I'm not so much worried about multitasking on the iPhone, since you're right that it's only currently preventing the (arguably) limited set of use-cases you describe.