It currently doesn't do fully hermetic configurations (as in, where it is impossible for any inputs to come outside of the project). Instead build2 does high-fidelity builds where it makes sure that if any of the inputs change (including options, environment, compiler itself, etc), the target gets rebuilt. See my reply to a sibling comment for some details. We do plan to add support for hermetic builds though it won't be exactly like Bazel's -- the idea is to prevent and, where not possible, detect external changes and fail rather than rebuilding.

Regarding caching (and distributed compilation), this is currently on the TODO list though a lot of the infrastructure is already there. For example, the same change detection that is used for high-fidelity builds will be used to decide if what's in the cache is usable in any particular build.

While I agree we should mention these points in the documentation (things are still WIP on that front), I don't think cross-compilation deserves mentioning: for any modern build system it should just work. In build2 we simply implement things in the "cross-compile first" way, with native compilation being a special case (host == target).

Does build2 handle the case where code has

#include "foo.h"

and then, after a successful build, you create a new file named "foo.h" in a directory earlier in the search path than the foo.h that was used in the previous compile?

It does but not in a way you probably expect it to be handled: i.e., with some filesystem mechanisms to make the update command only see what has been declared as target's dependencies -- I must admit I don't know Bazel does this in a cross-platform manner (Windows, Mac OS); copying seems way too heavy-handed.

In any case, in build2 this is "handled" by not including headers as "foo.h" but as <libfoo/foo.h>, that is, with the project prefix. You can read more on this here: https://build2.org/build2-toolchain/doc/build2-toolchain-int... And the proper fix will hopefully come with C++20 modules.