I’ve been able to convince C programmers to try out and use Zig just due to this unique ability alone, and to be clear, getting C programmers to seriously consider any language other than C is generally very difficult!
Having to consider another build system (with its own semantics), which the current Zig experience doesn’t require, changes the experience much more substantially than I think the Zig team realizes.
The big difference to the Rust ecosystem (or rather the 'cc' crates.io package which AFAIK is the current standard solution) is that there will be a Clang toolchain package with integrated cross-compilation headers and libraries that is used across all platforms instead of relying on a "platform C/C++ compiler toolchain" - which is the actually brittle part: different compilers, linkers and platform SDKs used on different platforms).
Ideally that same integrated Clang toolchain package used and provided by Zig could also be used by Rust to improve the C/C++/ObjC cross-compilation situation (similar to how the Zig toolchain is sometimes already used for this purpose).
Yes, this is a very good point. Zig remains unique and impressive in that sense. The fact that Zig compiles the correct libc and other system libraries on demand is actually another one of those, “How come no other language considered doing this before Zig?!?”
https://crates.io/crates/cargo-zigbuild exists though.
This does not seem bad in paper. One thing that does worsen with this is that in @cImport you could also comptime define preprocessor macros which was really cool, now that would have to be handled by build.zig I guess.