Yeah, but you don't need to virtualize the OS to do that. It would make more overhead.
It could be that the kernel uses only 80MB, but you have to take into account the caches and other structures used by it, which eat much more ram than that.
The OS can't be suspended, the user interface could be. But you don't need to run it inside a container to do that.
UNIX has a monolithic kernel, but Windows does as well (Windows NT is monolithic with some benefits of microkernel). So Microsoft could do the same as you are suggesting. I doubt neither would be doing it anyway.
You're kind of changing the roles of OS and games here. The OS is the one that must have the control to decide what runs and what not.
An OS that allows a program to take over the system has failed in its basic function of managing the system resources.
If you let developers control which application/process can or cannot be used when their game is played, expect the worse.
The OS moves programs or processes out of memory when they aren't needed, it has been like this since the beginning, but an address space reserved for OS is necessary, so the kernel uses it without fighting with other programs for memory. Letting the kernel and user space fight each other for memory leads to a big penalty in performance.
The kernel uses at most lets say 100M, you have to understand how unix works I guess. So its not just about the kernel - the kernel manages the hardware, above that in unix/freebsd is the init system, in linux thats now systemd, I wont get into any specific details, then come the service starts which is managed by the init system and finally the user interface, which is just another service (theres more to it like the initramfs which the bootloader uses etc, too much detail for here)
In windows land its straight from kernel to user interface, I stopped using windows many years ago, so I don't know the specifics of how their boot loader works, but you cant for example run windows without the user interface even the windows server edition without a ui actually boots to a user interface that does nothing, it doesn't dump you down to a shell.
The reason I mentioned virtualisation is because this is how PS3 worked, that's how they could support other os aka linux boot up, but with nvidia gpu inaccessible. I assume PS4 and PS5 (will) work the same, probably using something like bhyve. where the boot loader boots the freebsd orbis or whatever its called which then boots the playstation userinterface, but I believe this is done in a virtual instance - even microsoft is talking about virtualised instances for backwards compatibility, so obviously they are using hyper-v for this.
Essentially to have fine grained control of how many cpu threads and how much ram etc virtualisation is used, it might even be bsd jails (look at docker and cgroups to see what is available on linux - FreeBSD has bsd jails - I dont know if they have an updated version of this now) 1 advantage Playstation has by using unix is the extremely low overhead of the actual os, I could go into a lot of detail into this, but I reckon Sony have built the new UI from the ground up to be able to suspend to ssd and back while making use of stuff like partychat etc using apis, an api doesnt need a ui, so no ui overhead for game devs to access specific hw and os features. For microsoft to do this, it would be a lot of work, hence why they haven't done it, its not that they cant, they certainly can its software, but its a lot of work for them. I cant really be bothered to speculate on this anymore, we will know when sony releases more info, they haven't mentioned this we know for a fact Microsoft aren't doing this, at least not yet because they specifically mentioned amount of ram reserved for windows and 1 zen cpu core ie 2 threads reserved.