Linux, at the kernel level, doesn't have any concept of a "container". What you have instead are namespaces. File systems, process lists, networking etc. are all namespaced, and you can set these up "a la carte".
For example, you can create a new process that has as its file system root /home/blah. It will see every process in the system, it can do networking, etc. — but "ls" can only show the files under /home/blah, which appears as /. Inside this process, you can't see any files above this directory.
A Docker container is simply a process which has set all its namespaces in such a way as to isolate it from others.
"Entering" a Docker container is done by setting up your namespace to be the same as that of the container. For example, you can create a new process (a shell, for example) that is a normal process in every way — full access to the root file system and networking and so on — but has the process tree root as the container. The process will see only the processes inside the container.
You can do this on Linux today using the nsenter [1] tool. (This is also a way to create simple namespaced processes without Docker.) This allows a mix of namespaces; you can enter the container's namespaces but also retain the ability to run tools that aren't available inside the container.
In short, I assume the OrbStack debug command does the exact same thing. It's coincidentally the same concept as an ephemeral container on Kubernetes.
> In particular, mount namespaces are what Docker and runc use to give each container its own image and view of the filesystem. But unlike chroot(2), you can copy an existing mount namespace into a new one. Debug Shell uses this to copy a container's namespace, creating a new view where we can inject things without them showing up in the original mount namespace or filesystem.
