There are cases when providing service for remaining 2% isn't profitable. It's better just say "sorry".
I used to work in company where we have spent a lot of time making custom fixes for our software in order to work-around wired hardware/software bugs on machines of individual customers. Yes, we provided service for remaining 2% or so, but in cost of slowing-down overall product development and not making our product better for remaining 98%.
Your proposal still contains a security hole, since it still allows executing cmake or something similar. Adding sandboxing in some parts/steps of a build system has no benefits, as soon as the system as whole has loopholes allowing bypassing such sandboxing. It's like adding more locks to the front door, when the backdoor has no locks at all.
I didn't say one should not use thirdparty dependencies at all. They are sometimes useful. But they should be chosen carefully and ideally reviewed. And any updates should be done manually in order to prevent security chain attacks.
Having a standardized package manager allows lowering the bar and bypassing careful thinking. It has also a cumulative effect - if one adds each dependency in its project one by one with proper audits, transitive dependencies may not be managed so carefully. And then we have cargo-style cancer with trivial projects having hundreds of dependent packages.
For me this happens from time to time. But it's for a good reason - I develop my own compiler. And it can be pretty tricky to identify and track such bugs.
I think it's actually good that C++ has no standardized packaging system. This forces one to think carefully before introducing a dependency, since often such dependency have hidden costs, like security vulnerabilities. Since many critical systems are written in C++, it's too much risk to depend on dozens of easily-accessible third-party packages without properly auditing each of them.
I see no benefits in sandboxing such things as build systems. Sooner or later one eventually needs to execute some external code, like a shell script or cmake. And these external programs can do whatever they want. So, caring about sandboxing within a build system executable is just creating a security theater.
It's even worse. Learning Lua may be at least a little bit useful for other tasks. Learning some language specific for this tool is just waste of time.
I am pretty skeptical about the whole idea about adding such exceptions to the single mutable reference rule. It may be safe to share references to simple structs in terms of raw bytes access, but as long as some non-trivial invariants are involved, it can be a source of nasty bugs.
In my programming language I generally don't allow having more than one mutable reference to a variable. The only exception is when two references point to different elements of structs/tuples. This gives some flexibility without sacrificing correctness.
> Because of this, Ante code can safely have multiple mutable borrow references to the same struct at the same time.
I doubt it can work in multithreaded code. Allowing sharing mutable references (even to simple structs) means race conditions, temporal inconsistency between different struct fields and even incorrect read results for basic integer types (if the target CPU can't atomically read/write values of types like u64).