Yes

That’s called containerization

You can use appimages, more importantly if you make a directory next to the appimage with the name of the appimage + .home the appimage will also set that as its $HOME that way you can also keep the configuration files of the app separated from the host OS.

You can also sandbox appimages with aisap.

Distrobox

Docker, Distrobox, Toybox, systemd-nspawn, chroot.

Technically those all rely on the same kernel namespace features, just different ways to use it.

That’s also what Flatpaks and Snaps do. If you only care about package bloat, an AppImage would do too but it’s not a sandbox like Flatpak.

Snap turns your system into a slug at boot time, makes it take forever to shut down as it unmounts fifty memory file systems, scatters files all over the place turning a neat organized system into a pile of shit. I primary run Ubuntu, but I excise snap from it as one of the first orders of business.

IIRC that’s the whole point of flatpak, snap and appimage

Docker can probably do it too, distrobox puts a useful wrapper on that

Nix does that kind of, nix packages aren’t isolated in that they can’t access resources on your system but all dependencies are stored in the nix store, hashed and isolated from eachother, and wiped when you collect garbage

Go with one of the ready to use systems. Flatpak, Snap, AppImage. Snap is largely Ubuntu Ecosystem, Flatpak is independent. AppImage is an option if you do not need/want a Sandbox.

Stay away from Docker and LXC for this use case (graphical applications), they are much more work to get going.