I think from what I’ve read that this is the case, but I’ve read some other info that’s made it less clear to me.
On the second part of the question regarding container engines, I’m pretty sure that may also be correct, and it kinda makes me wonder a little about risks of engine lock-in, but that may be a little out of scope.
In my experience docker will run Linux images everywhere. I believe it uses WSL on windows and a VM on macs.
So it entirely depends on what your engine supports.
I believe there are open standards for the binary format of images so switching engines may be possible. But again depends how the containers are built.
Containers are practically a linux thing. The specs to run containers are open (Open Container Initiative). That’s why if you aren’t on linux, the most common solution is to virtualise linux or add a layer that translates linux syscalls to those on the host OS (e.g windows subsystem for linux). Once the linux environment exists you have multiple orchestrators (docker, podman, kubernetes, etc.). They all either have their own runtime or use an existing one (runc, crun, youki, …).
I haven’t read the OCI specs, but IINM containers are built upon linux primitives (namespaces, cgroups, and I forget the rest).
Linux distro is entirely irrelevant. Almost always, the distro is just a particular way of packaging things.
But also, assuming you’re talking about “docker” containers (or rather, OCI containers), then no the OS running the container doesn’t matter. That’s the whole point of containers.
Also what do you mean exactly by “container engine”? Do you mean docker? Because “docker” containers can run on podman, kubernetes, etc