I would not think that processor speed would be a significant issue for multi-tasking. The road-block for multi-tasking on iPhone is RAM.
If multi-tasking will be enabled only on some models, I would assume it would be only for 3GS (+ later models) and iPad. Both have 256M of RAM. Clearly, Apple did not feel that the iPad needed any more memory than that, and I also assume that they anticipated enabling multi-tasking.
The 2G and 3G models are quite constrained with only 128M of RAM and no swapping. (The kernel is perfectly capable of it, but swapping to flash is impractical.) Considering the memory used by the OS and "native/Apple" applications, the 3GS approximately triples the amount of RAM available to third-party applications vs. 2G/3G.
One more assumption - and a prediction - Apple will enforce by technological means a limit on the amount of background processing applications can do. Some developers will bitch, but, IMO, those that do will be those who are less talented. I would be perfectly happy if allowed to use 1% of the processor power in background. But I'm guessing Apple will allow something like 5% to 10%. Nobody needs to do Folding@home or what-not on their battery-operated phone.
I also wouldn't be surprised to see some enhancements/tweaking to some APIs (which may or may not involve changes visible to developers in the form of changes/additions to interfaces) for dealing with shared access to, say, GPS and audio services. I can see many users running several (perhaps as many as 3-4) location-aware apps in background, and it would make sense to avoid as much unnecessary duplication of processor power.
I can also see some limited "swap me out" capability, but, again, strictly limited, to avoid exhausting flash memory life. I would think this would be something that would be done at the request of the app (in response to a "user is switching away" message). Perhaps simply some ability to write r/w data segments (as opposed to r/o data segments which would typically contain the executable code) to a file, and to re-constitute an app from the executable file and the saved r/w segments. This would save the overhead of serializing and de-serializing data.
This would be good for apps (such a GPS turn-by-turn direction apps) which have to load a significant amount of data into RAM at start-up. This would allow these apps to be put "on hold" while another app is brought to the foreground, without having to go through such an extensive initialization process to re-start them. If these apps could also do some limited background processing, so that they could bring themselves back to the foreground (say, if something important happens, like you have a turn coming up...) that's better still. And with some ability added to the location API so that the OS could wake-up an app at a certain location, or after a certain distance, that would be ideal.
One enhancement that might be needed for this would be a change in the way the Mach (BSD-derived) kernel handles backing store for swapping. Actually, I dunno how Mach does it, but I am familiar with Unix/Linux and Windows, and the Windows approach does have a significant advantage here. I'm assuming that Mach works similarly to Unix/Linux. In Windows, the executable file (.exe) acts as backing-store for read-only code segments. When code (as opposed to data) is to be "swapped out" it is simply discarded. When it is needed again, it is reloaded from the original .exe. There's no need to swap out code - just data. There is one negative to this, which explains the relative ease of hot-updating Unix/Linux/OSX - updating on Windows almost always requires a re-boot, because overwriting an .exe (or shared library, as well) for a running program (or the kernel) would be a disaster. It almost never requires a re-boot for unix-like OS's, because there's no need to go back to the executable file to swap-in. This is not an issue on the iPhone, though, which always requires a re-boot for a (system) software update anyway, and you can't update applications while they are actually running. For OSX, then, I could see some serious issues but for iPhone OS, not a problem.
