systemd-nspawn vs chroot and bind mount?

• virtualizes the file system hierarchy

It uses mount namespaces. It's more powerful than chroot because you can mount and umount filesystems under your namespace and those will be hidden from the outside, or from other mount namespaces.

Take a look at this article on Linux namespaces (and, in particular, mount namespaces) to have an overview of what they do.

• as well as the process tree

That means you get new PID numbers inside the namespace. PID 1 inside the namespace could be PID 12001 outside it, PID 40 inside it might be PID 13987 outside it, and so on. In particular, not all PIDs are mapped inside the namespace, so if you use a command such as ps -ef inside it, you'll only see processes that are in that namespace, and not ones from the outside, or from other pid namespaces.

The article mentioned above also gives a nice overview on PID namespaces.

• various IPC subsystems

Shared memory, semaphores... The stuff shown by the ipcs command. Again, that article I pointed out has a bit more on that. (If you haven't heard of SysV IPC or the ipcs command, you can probably ignore this one.)

• host and domain name

This is actually the UTS namespace, and once again, that article has more details.

It virtualizes what the uname command returns (you can take a look at uname -a inside the container.) Also, hostname and domainname commands. Yes, the two /proc files you mentioned too.

So, in short, this is telling you that systemd-nspawn is using Linux namespaces to give you container isolation. That's also what other container technologies (such as Docker) employ.

There is also an important limitation of systemd-nspawn: you can only have one instance at any one time, while chroot allows you to chroot multiple times into the same directory.

That means that if you use systemd-nspawn to "chroot" into a directory, you cannot run it again from e.g. another shell until the first instance exits.