> There are very good reasons why you you would both want to actually close programs
Other way around: modern OSes don't want to make it look like programs aren't running when they really are (which has been possible ever since installable background services were created); modern OSes want to be able to close programs behind your back, while they seem to still be running, and then restore them to their previous state when you come back to them.
And it's insanely idiotic. In the mobile world we have this due to a vastly different UX, and traditionally very limited resources. Remember the first iPhone didn't allow more than one app running. Today phones have fast CPUs and plenty of RAM, it's mostly about not draining the battery. None of these constraints apply to the desktop. Even on laptops power consumption is much less of a concern, unless you have some program going berserk spinning on 100% CPU.
So trying to bring this same concept to the desktop is insanely idiotic. Microsoft failed miserably by making Windows 8 a phone OS and then bringing it to the desktop with minimal changes. Windows 10 improved so much by actually focusing on the desktop again. Including such no-brainers as allowing store apps to run windowed. I'm not a Windows user anymore myself, but none of my friends who still have it as their daily driver like or use apps.
> modern OSes want to be able to close programs behind your back, while they seem to still be running, and then restore them to their previous state when you come back to them.
I thought they were suspending them, not closing them. Those are very, very different things.
In any case, pretending that applications aren't closed when they are is no better.
What is “suspending”? Like what https://github.com/maaziz/cryopid does? No OS uses such a technique for production process management. (Well, I guess you could say that Genode does if you consider VMs to be processes.) Processes are too non-self-sufficient for this to work with full generality. (For example, what would a process do if it “freezes” in the middle of executing within a shared library’s code section, and then an OS update is applied, replacing that library on disk? The “defrost” process would presumably re-run the dynamic loader, putting the new version of the library into memory; but now the defrosted thread’s PC points into the middle of an instruction. Oops!) CrypPID-like techniques only work in controlled environments, like if you’ve got a machine serving solely as a Docker container host and you want to “pause” containers.
On the other hand, if by “suspending” you mean “the OS asks the program to persist its running state to disk, which it can easily do because it’s using GUI-control and scene-graph frameworks that know how to serialize out their current state”—and then, when it has done this, the OS considers the process “clean” (like a clean page of disk cache) and therefore discardable—then yes, the OS is suspending processes.
Keep in mind that you need to add a flag to your application’s OS-readable metadata (the application manifest in Windows; the Info.plist in macOS/iOS) opting into this behaviour, signalling that your process is okay with being shut down at any time when it’s in the OS-visible “clean” state, and isn’t, say, a host for an RPC server that other applications are expecting to have a stable connection to.
Other way around: modern OSes don't want to make it look like programs aren't running when they really are (which has been possible ever since installable background services were created); modern OSes want to be able to close programs behind your back, while they seem to still be running, and then restore them to their previous state when you come back to them.