If you're surprised by Zig's comptime, you should definitely take a look at Nim which also has compile-time code evaluation, plus a full AST macro system.
[1]: https://github.com/nim-lang/Nim/wiki/Organizations-using-Nim
Alternatively, there is also a Nim effects tracking system that lets the compiler help you track the hidden control flow for you. So, at the top of a module, you can say {.push raises: [].} to make sure that you handled all exceptions somewhere. So, it may not be as "Wild West" as other exceptions systems that you are used to.
As with so many aspects, Nim is Choice. For many choice is good. For others they want language designers to constrain choice a lot (Go is probably a big recent example, because fresh out of school kids need to be kept away from sharper tools or similar rationales). A lot of these prog.lang. battles mirror bigger societal debates/divides between centralized controls and more laissez-faire arrangements. Nim is more in the Voltaire/Spiderman's Uncle Ben "With great power comes great responsibility" camp, but how much power you use is usually "up to you" (well, and things you choose to depend upon).
Will this transitively enforce exception handling? i.e. if a 3rd-party dependency that I am using calls into another dependency that raises exceptions, but doesn't handle them in any way (including not using that pragma), will Nim assert that? Otherwise, that's precisely the function coloring problem I mentioned: if you can't statically assert that a callee, or it's descendant callees, doesn't throw an exception then you have to assume that it will.
Yes. The module you put the pragma in is about the "roots" of the call graph, but it covers the whole call stack from those roots down wherever the code is defined. Sorry I didn't make that clear enough { but in my defense I was trying to address the problem you raised. :-) }