I'm not disagreeing with this. My point is rather; it's a more complex mechanism to take care of on the OS level than it is if developers would program their app/game with this in mind.
Remember; doing it on the OS level mandates a consistent experience - a flawless working mechanic, if you will. And I have my doubts if it really is as simple as simply dumping memory to a harddrive and dumping it back for a
quick suspend feature. Quick in italic because as mentioned; copying 4-6 GBs of data probably isn't all
that quick at the end of the day.
It's a bit like having the suspend feature on my laptop. It comes in handy here and then, more because I multitask a lot with 5 browser windows open etc, but ignoring multitasking/multiwindow usage (which doesn't apply to consoles anyway), shutting off and booting up a complex OS like Windows is actually quicker. So, I'm basically comparing the workload it takes to implement this on the OS level with the practicality of the feature in the first place.
I'm going to be very interested in how they are going to solve some rather unpredictable situations too; for instance; what happens if I suspend the game while the game is in the process of installing content, or saving a game-save? Lets not forget; the game has no idea what the OS is doing and the OS has no idea what the game is doing. Is it possible for a game to set a flag saying "disable suspend mode because I'm right in the middle of doing something that might seriously f up if you do"? Then again, how does Vita solve it or other portable systems that handle power-off and resume?
I'm actually suprised there are people excited over this; if we were still playing games without the ability to save at all, I could understand it - but the ability to save your progress (together with rather quick loading times) have kind of made this an overkill feature - IMO of course.