Chicken-littleism to you. Legitimate concern to others, especially given the derth of information out of Cupertino.
A lot of the new user-interaction stuff in Lion has me concerned. Not a "oh-no-what-hath-Apple-wrought" way, but moreso, "Uh, I'm not sure how this is going to work out, and I have lots of questions about it, and how it'll impact my workflow. I guess we'll wait and see."
For what it's worth, I am a software developer. I do have a fairly grounded and educated perspective on what will happen at a macro level of the transition of this feature to OS X.
We already know how this will work. The API is developed. It is a back port from iOS to OS X. You do not re-invent the wheel to move an API from one code base to another that shares 80% of said code. There will certainly be various changes to accommodate the new environment that is not quite so resourced constrained. But the *doom and gloom* scenarios being painting in this thread *will not happen*. Accept it or not, it's reality.
I will re-iterate. Any current application (or future app linked against pre-Lion APIs) will be entirely unaffected. If you close the app, the app will go through it's shutdown process, just as it does now. The executable itself will remain cached in memory. You're computer is already doing this now. All modern desktop operating systems employ some form of caching, Snow Leopard is no exception. The responsibility is just moved to a different set of technologies in Lion.
Secondly, there are no adverse effects for OS memory use or apps that DO use the feature, providing they are properly written. The OS dumps suspended apps as needed, without impact to system performance. Again, it's a caching mechanism as well as a multitasking mechanism. Understand that an app that supports suspend, and is in a suspended state, is, at that moment, effectively the same as the app that does not support suspend. It is not running, it is not sending packets of data over the internet, or communicating with other processes on the system… it is completely halted; but it is cached. The system may choose to toss it when it is in this state, and it is entirely safe to do so.
Unlike unsupported apps, the supporting app adds the ability (operable phrase being "ADDS the ability") to come out of that closed state and right back to where it left off. Supporting apps are intentionally designed with the ability to suspend, resume, or cold launch due to having been jettisoned by the OS while in a suspended state. That flexibility is a fundamental part of the design. It's designed that way to actually prevent the very same problems people are freaking out about.
If you feel compelled to needlessly panic without understanding how the system works, go for it. I don't know if you are one of them, but there are plenty of people who seem to make a hobby out of uniformed speculation. Who am I to judge? Spend your forum time as you wish. It will be made clear soon enough what the reality of the situation is. The concern over app suspension is as Chicken Little as Chicken Little can get.
P.S. The app suspension features is not the first example of a significant, underlying system API being back ported from iOS to OS X. Core Animation was developed for iOS. It was then ported to OS X. Interestingly, it actually ended up debuting in Leopard first, before the introduction of the iPhone.
