A bit off-topic, but since you mentioned it, why is Zig a "seriously flawed language"?
This results in miscompilations, broken buildins, features added that are then ripped out again.
I think fast iterations and experimental stuff are ok if you have a stable core. I.e. I don't mind if zig decides to change its for loop syntax after 5 years, so long as there is a simpler stable construct like `loop { break; }` that people that use the language in production and library maintainers can use.
You need a certain critical mass for a language to be self sustaining, and that requires people to actually use your stuff, which in turn requires at least some stability guarantees for some subset of the language.
Zig's response to that is "I'm just my inventors toy yet, but it will be grand when version 1.0 hits in 10-50 years."
The fact that they now want to replace LLVM with their own backend makes me think that even 50 years would be optimistic.
To be fair go has never used llvm and was delivered in less that 50 years.
And if Zig was a google project instead of a 3 person show, I'd be far more inclined to believe that they can pull this off.
But as previously said, the current style of development makes it hard to attract contributors and more importantly funding.
Getting to 70 percent of llvm will be relatively easy for zig and like all others, they will congratulate themselves and pretend it validates their choice. They will then discover the other 30 percent happens 0.1% at a time, because there are no silver bullets. This will take them 10+ years because it always does.
Not linking to LLVM would also make the barrier to entry on contributing to Zig itself lower, because now you can just compile Zig with Zig, and not worry about other dependencies.