The thumbails could be live, if the application developers chose to allow it. The stock music player still updates it's UI when mimimized, but it only does so every 10 seconds rather than at the same rate as when maximized. This saves quite a few CPU cycles, since it's likely that the music player will spend a lot of time in mimimized state. I imagine the clock application behaves in a similar way, with the hour/minute hands still being updated, but not the second hand.

in fact even the clock icon in the main menu view is update occasionally. haven't figured out on which basis. sometimes it is stuck for nearly an hour, sometimes it updates after a few minutes...

I can confirm it:

I am fairly positive that multitasking is the same. The OS doesn't do anything to freeze your app. It's up to the developer.

I don't understand how an OS gives good options to help developers determine how his/her app uses phone resources on background is inferior in multitasking. It's not logical for most apps to provide high visual changes operating on background, it's a waste of clock cycle, battery, electricty, fossil fuel and trees.

the fossil fuel, trees and all aspects are maybe more relevant in a general smart versus dumb phone discussion then in a multitasking discussion... tasks running quietly in the background are probably more efficient then if the tasks have always to stop and resume whenever they get the focus back.
but that's just my gut feeling (inactive tasks are more likely to be swapped out of RAM, thus time / energy needed to get the data & instructions back from storage aso.)
of course, if the active tasks use up all the available working memory, swapping will become a performance and thus efficiency issue, but the N9 has 1 GB of RAM, plenty to go for your average mobile apps.

either way, "smart" phones are energy sloth's
then again, that comes with the territory.
being on-line thus connecting to a cell tower all the time to check statuses and mail boxes uses a tremendous amount of energy
period.
if on top of that you want to post pictures with location, or simply give updates about your (exact) location (thus using GPS), well, you may not even make it through the day with one charge.

use a N9 simply to make or receive calls and maybe send an SMS every now & then & you are good to go several days with one charge, especially if you disable the "default" saving screen and make it a black slab ¦-)))

all in all, the energy consumption isn't caused by the hardware or even the OS, even though hardly any Linux (or BSD) based mobile will ever get close to the energy efficiency of Symbian but by the "usage", respectively the "hype" of always having to be on-line & "updated" & all that
and lets not even start about m$ crap.
lucky if you can do your daily shuttle with one charge >¦-)))))))))))))))))))))))

just turned off all networks & put saving screen to "black" on my N9
will see how long it goes, doing nothing
last few days i had it in Flight mode (thus without network but with the default clock displaying the time in HH:MM; uses about 6 mA in that state...

I think you misunderstood what I said. I didn't mean to say task should get suspended and reloaded like Windows Phone. I meant task should have no need to provide visual updates in real time while minimized

It should always provide visual updates with opt-in or opt-out system chosen by user...I point my browser to an auto-updating site and it doesn't update when minimized hence live scores are made more difficult to follow...Thanks to a developer I got a test browser especially for this purpose...

my favourite file manager?
Midnight Commander
works from any command line (providing framebuffer)
thus, i am a command line junkie, and i couldn't care less about "visual".
however, even on a command line it is nice to see whether a command is still running with a quick glance (minimized) without caring what files / stage is being processed...

this is being said your argument is trollish.
if an OS supports multi-tasking, it is unwise to stop "just" the display update, unless it is completely hidden in which case the display feeds are simply disabled.
in command line this is achieved by redirecting standard output stream to /dev/null.
what about standard error stream (#2 in shell parlance)? goes to /dev/null as well?
what if the process hits an error and needs input from user?

freezing a view of a running process is asking for (code) trouble.
the last step before the dreaded "blue screen of death" LostDOS users are so familiar with >¦-)))))

Oh I'm trollish? Please read carefully what I said. I said and I quote "I don't understand how an OS gives good options to help developers determine how his/her app uses phone resources on background is inferior in multitasking."

Keyword is good option, understand? N9 has good options to freeze the visual update or let your app running wild while minimized. It's up to how the developer want to use it. The compass app is the perfect example.

Last I checked, terminal updatew visually while running on the multitasking screen.

Jesus, can you guys stop cringing everytime someone mentioned "Live", "Update" and "Multitasking" in the same sentence?