In addition, there are events notifying application that it is going to be "hybernated"; basically it tells it to save whatever information it needs to restore into current state.
The "background slots" are implementation details. Applications do not receive the event "you are going to be killed, please serialize" the same moment they lose focus; they receive it at the system's discretion. The system decides based on memory available (mostly), whether it will leave some processes running or whether they will be "backgrounded" (basically, what is more economical - backgrounding processes all the time, when the user is switching between two apps, or just keep them both in memory?).
To some extent, this is tunable by the power users - if they download "Dev Tools", they can set the limit to 1 - 4 processes (or unlimited). It is basically trade off between memory consumption and responsiveness.
I repeat - this is not supposed to be setting for common users; it is just exposed for developers to experiment, what happens when they push the decision threshold in one direction or another. The system is supposed to have good default out of the box and manage the processes automatically (which is also reason, why there is no task manager).
* Existing iPhones offer an infrastructure to quickly save and restore the state of your application so that it can be "hibernated", therefore reducing the need for real multitasking.
* Obviously, due to the limited display size of mobile devices, you can't have two apps running on the same screen at the same time, it just doesn't make sense, so an "inactive" app is off the screen, hence most of the time it doesn't matter if is actually running or hibernated. Just like on the iPhone.
* Sometimes, you still want your app running even when it's off-screen. Things like music players (Spotify for instance), mail tools (gmail fetching email in the background) or social tools (a twitter client fetching the latest tweets that you can read later even if you don't have signal).
* Notice that generally, for things that you want to run in the background, you don't need an active UI. There's no need for UI for an audio player in the background, a mail reader syncing in the background, etc.
* Solution: disallowing code that is eligible for running in the background to have access to the screen. This will make he background tasks a lot leaner as it would force developers to separate "service-like" code from "application code" and enforcing strict memory/CPU limits on "background services".