Multitasking on Windows 8 metro apps works almost the same way as in Windows Phone 7.5+ (after mango).
Let me explain it:
As it has been already explained before, closed metro apps go into suspended mode.
But it doesn't mean that they don't have multitasking.
They don't in the sense that they can't multi-task themselves directly, as suspended tasks are not allowed to run any code.
This was created so it won't have any impact on system whatsoever.
But the problem Microsoft faced was with multitasking.
They couldn't allow suspended apps to directly run in background for multitasking as it would destroy the purpose of suspension.
Thus, Microsoft has created background tasks. Those are tasks that Metro apps could take advantage for multitasking.
Apps can't run directly but they can use API for these background tasks to accomplish tasks they want.
For example:
Push and toast notifications. This is used for periodic checks, like mail and live-tiles. This way Finance and Weather app can update its live tile.
Playback Manager is used for music and video as mention above with Music and Video apps.
Background transfer API. You can try this one with Metro IE. Start some large download and leave Metro IE. Even though IE goes into suspended mode, download will still continue.
There also possibilities for sharing, printing, synchronisation and etc.
There is also background tasks for VoIP and chat clients.
So with this model, Microsoft can assure that suspended Metro apps won't abuse their power and have any impact on system while still being able to do background tasks.
Background task service makes sure to have minimal impact on foreground process.
If you are really interested and want more details there is a whitepaper about it:
Download: Background Tasks - Microsoft Download Center - Download Details
EDIT: In the scenario of 2 monitors, metro app is considered as still active/running, thus it should not go into suspension. ( As far as I know)
From whitepaper:
Windows 8 Consumer Preview (referred to later as Windows 8) introduces a new model of app behavior. Metro style apps in Windows 8 are full screen and the user is expected to interact only with the app that is in the foreground. The foreground app is assumed to be the most important to the user, so this app receives all the resources of the system. When an app is not in the foreground, it is suspended, and cannot run any code. A suspended app remains suspended until the user resumes it by bringing the app back to the foreground. With this model of app behavior, the user experience is never impacted by lags or delays caused by the execution of unimportant background apps. In addition, reducing unnecessary background activity optimizes battery life on a variety of form factors. The time taken to resume a suspended app is negligible and would appear to be almost instantaneous to most users.
Windows 8 provides a number of features to make an app update content even when the app is suspended:
• Windows push notifications can be used to keep the app tile fresh and up-to-date.
• Playback Manager can be used to play audio in the background.
• The background transfer API can be used to download and upload files in the background.
• File share contracts can be used to share data between apps.
Push notifications and the background transfer API are optimized for system performance and longer device battery life, so it’s best to use these features whenever possible. If a suspended app must run its own code to do other kinds of work, Windows 8 provides apps with the ability to create background tasks.
Appropriate scenarios for background tasks
Allowing apps to run code in the background when they are suspended is a powerful feature and is designed primarily for the real-time class of apps such as mail, VOIP, and chat apps. The background task execution environment is a restricted resource-managed environment, and background tasks only receive a limited amount of system resources. Background tasks should be used for small work items that have no interaction with the user and only provide limited service. Long running or expensive workloads in the background will deplete the user’s battery and are not an appropriate use for background tasks.
Scenarios that are appropriate for background tasks include downloading mail in the background, or showing a toast notification for an incoming VOIP call or a chat message, or reacting to a change in system condition (for example, UserAway) and updating the server with this information. Scenarios that are not appropriate for background tasks are indexing mail, transcoding photos, running SETI type workloads, or anything that requires user interaction through displaying UI or audio.