Colima is all you need now, it's basically a drop in replacement for docker desktop. There are actually very few container runtime engines (containerd and runc are the big ones) and all the tools you read about just wrap that lower level container runtime. They're all the same when you get down to it and just have different opinions about config, networking and storage.
Every tool says its the same but they aren't. You'll eventually run into some issue that wouldn't have happened on Docker, and as soon as a dev spends two hours on it you've paid more than you would have paid for a Docker Desktop license for that dev for the year.
I believe NixOS does not (there's a "nixos-rebuild switch" command that sounds vaguely like it requires a reboot, and NixOS does aim for declarative confgs, but it knows how to restart services etc. without rebooting your whole machine - see chapter 3 of the NixOS manual: https://nixos.org/manual/nixos/stable/index.html#sec-changin...)
But the proposal here isn't about running NixOS as your OS, since we're talking about macOS. It's about using Nix as an additional package/environment manager on top of another OS/kernel, in this case macOS, though of course Linux is well-supported too.
Each file in Nix is stored in a path that's computed based on the hash of the relevant source code, and depends on other files (e.g., libraries) via their hash-based paths, too. So you can straightforwardly have multiple execution environments with their own dependencies that don't interfere. It's an alternative solution to the dependency problem: containers leave paths alone, but create a new root filesystem for each container. Nix programs all share one root filesystem, but modify the paths so nothing uses e.g. /usr/bin or /usr/lib.
Precisely because Nix binaries isolate themselves from /usr and carry their own dependencies, the Nix packaging repo "nixpkgs" can be used on any Linux machine, not just NixOS ones. And the Nix folks also build nixpkgs for macOS, so most software in nixpkgs can be installed on a macOS machine too. This gets you a solution to the dependency problem on macOS itself (because there are no Linux-style containers on macOS). If you want, it also gets you a relatively consistent dev environment for applications that will be eventually deployed on Linux: although the kernel is different and of course the binaries are compiled for different kernels, the entire userspace can be the same on macOS and Linux.
nixos-rebuild switch does not require a reboot. In fact, you'd typically use nixos-rebuild boot if you don't want immediate changes.
For very complicated reconfigurations, it might be advisable to reboot if that involves changes to services that are only started during boot time. But that's the case for nearly any OS...
`containerd` invokes `runc` (and `docker` can also invoke `containerd` via its API, which then invokes `runc`). The "lower level container runtime" is cgroups and various kernel namespaces (primarily process and network, but some others are included). There's no magic there.
They are not all the same when you get down to it, though. The "different opinions" about how to plumb traffic back out from a container (DNAT/SNAT via a bridge, macvlan, whether using a CNI directly is supported), whether a service/daemon should be the primary entrypoint (docker, containerd) or whether it's optional (podman), whether they speak to runc at all (containerd/docker yes, podman defaults to crun, kata is also an option, and others), what kind of storage overlays and plugins are allowed, etc are more than "opinions".
The devil is in the details. Colima is "basically a drop in replacement for docket desktop" under the assumption that you aren't doing anything very complex with Docker. In particular, complex networking is likely to fail/explode.
Compose is a layer on top of the Docker client/API, so the container runtime provider shouldn't matter, I guess as long as there's a real dockerd under the hood, and modulo any bugs.
