Zig build scripts are arbitrary zig programs, so sandboxing those scripts is a Good Thing. Wasm might be overkill, but using something off-the-shelf that's specifically designed for sandboxing untrusted code is definitely the right approach.

sandboxing, which feels a weird way to achieve that. Although the reason for it to begin with is because builds systems can typically access raw memory and disable artificial restrictions.

I think this is a bad move since the real fix to these attacks is a sandboxed environment rather than a single tool implementing sandboxing.

Not a lot if you're going to run the code anyway.

But when looking at open source code you don't trust yet, you might want to build code, without running it, so your development tools will work.

I just got so fed up with Starlark trying to do a nontrivial RBE prelude that's fairly different than Meta's.

I added WASM/WASI bindings and wrote the prelude in Haskell.

Both the bindings and the prelude took less time than I already wasted on multiple attempts in Starlark that all collapsed into string goop.

It's nice to be able to bound the execution environment in a build tool but still use a serious programming language.

Given Zig has excellent support for targeting WASM, seems you'd get the same advantages.