I like Dusty’s idea of contexts. I don’t think you’d get too far with the everything being a container , making the boundry fuzzy depending on how much you can bend something to fit into this would definitely be better as a migration path.
Just some ideas being thrown out here for the desktop, pick the ones that make sense and throw away the rest =).
I started doing this after trying out Plan 9 for a while, the idea there was that everything essentialy has a view of its own of the system, so disabling networking access was taking away /net access from the process (since everything had a file system interface to do things) and so on. Mounting another system’s /net meant tunneling all your traffic through it, so running a session or process with a VPN meant doing so. Linux’s clone and namespaces come from Plan 9, so I think the same logical extension fits better here too (except that not everything is in the filesystem so we have more resources to share, the idea remains the same).
More here on the history of things: https://lists.gnu.org/archive/html/coreutils/2015-07/msg00037.html
I think modularity really helps in this regard, and helps me do some things I am outlining below:
Run every session with a mixed root image of its own: So, I have a root filesystem with the bare essentials, and then a root with more stuff added on top, depending on things I want to use in that session (so I can have the latest GNOME from F29 while still not upgrading from f28). When versions are same, I merge the two roots with overlayfs and hope for the best, otherwise use the full blown GNOME chroot as a basis for user@.service. That service also has options to out the session in its own PID namespace, in its own User namespace, in its own mount namespace (so that usb drives I mount in it aren’t visible to the root context), and so on. This effectively allows one to isolate the user, and potentially even being able to run their own full blown distribution -something different from fedora. Now, one could argue if the GNOME stuff was its own systemd service, all of those could use their newer “runtime” and run the latest version, yet my shell and so on still pointing to my user runtime (this is hard when gnome-terminal is a service spawned by systemd --user running in a context I don’t want, so I just shell out to systemd-run).
I’ve also been thinking of adding a restricted version of this and use the login to directly launch a remote screen to my other desktop (so consider entering user=dom/user) and making that session effectively a guest session (with dynamic uids) so you can’t break out of it and do things to the real machine, but wrapping this has been quite hard (I’ve been trying a console DM called ly so far because making gdm do this doesn’t work, really).
The result is that different components are dynamically updated, and adjusted, so a stable system underneath but a bleeding edge GNOME and flatpak apps, and the user locked down in that session, shelling out to systemd-run and machinectl shell for running in the host context (since PID1 forks off these and is unaffected by our changes) and directly logging in to remote machines as if it were local (the key is making the user feel that it is a native machine).