Lets not go to too deep in this OT, but the terminal window program's backend could (should) be programmed to be Service and IntentService and it could do just that what you describe. Terminal's GUI would be a normal Activity which connects to that backend which is running CLI processes and bash. The GUI part could be killed in between when a user leaves it (the terminal window) to the background. Like I wrote, all code wanted to be run in the background should not be an Activity but a Service. It is easy for a programmer to know in advance, but hard for the OS to guess which code is wanted to run in the background no matter what. And it wastes battery life if we assume just all code to be equal in this sense.

Android seems to have done it right, because so many "normal users", like my mom, grandma can use Android-phones and Android-apps, even something like Samsung Mini (384 MB RAM). 80% market share (and necessity Jolla to support Android apps) would had not come if it just wouldn't work. Also Android's Java just seems to work good as a developing language and platform. It guides even bad app developers to make somewhat working apps which won't bring the whole system to its knees even if behaving badly.

About future of Jolla's Android app-support. I think it would be good if in the future the Android apps which are in the Pause- or Stop-state, not yet killed but resident in the RAM, would show in the Sailfish's task manager as separate apps. There could be a setting for ACL, whether user wants to show just one ACL subwindow in the task manager like it is now, or all Android apps which are still in the RAM-memory (Running, Paused, Stopped) or the latest run N Android apps (like the default task manager in Android shows them). Especially if Sailfish is ported and sold later to endusers with hardware like Note 3, which has 3 GB RAM, a user can then easily run several Android and native JollaOS apps and quickly switch between them through the task manager.