Comment by jcranmer

I feel like the biggest issue of all is that bootstrappable builds are by and large solving the wrong problem. The main concern of bootstrapping is the existence of packages that require on older version of them to build themselves, because if you end up skipping a version for whatever reason, you may end up without a clear way forward (this isn't a theoretical concern--Debian gradle packaging is horribly broken because of this, and they've been trying for years without success to fix it).

When you have a build dependency on one of multiple stage 0 compilers, the problem of a cycle basically disappears. You need a C++ compiler to build a C++ compiler these days, but you have your choice of two C++ compilers, so the probability you wake up one day without a working C++ compiler that you need is quite low. And the mostly theoretical trusting-trust problem basically disappears on the second stage 0 compiler availability, so the marginal benefit of a third or fourth or nth stage 0 compiler is basically nil.

And yet, the vast majority of bootstrappable build efforts are basically focusing on "how do I go from, say, a hex editor to a working C compiler," which is one of the least useful efforts imaginable. You can sort of see this with their project list: they highly tout their efforts to get to gcc from "stage0", and when they start talking about Java, it instead becomes "here's how to build a 20-year old version of Java, but, uh, most of this stuff is unmaintained so good luck?" And the JVM languages are in a state of "uhhh... we don't know how to break these cycles, any ideas?"