First, we'd love it if you would try our early container prototype on your build. Contact us and we'll add you to our closed alpha test. Also, we can send you the full paper (preprint) on the Debian case study, with the gory details.
I would never argue against patching tool chains to make them deterministic. If I were the maintainer I would always accept these patches! (And the GHC community we're part of has made some efforts on that front.)
You raise an interesting question regarding bootstrapping which I believe is similar to the good old Ken Thompson "Trusting Trust" attack: https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...
Well, there's always some trusted code base (even with Coq), but I would argue that it would be harder for us to execute the trusting-trust attack in a container than in a compiler like Ken Thompson's original. The compiler can inject malware when it recognizes that its compiling itself, but we run arbitrary build systems, compiler tool chains, JITs. On top of that, one can build the container itself without ever using the container, so we wouldn't have an opportunity to inject.
Any containers or VMs that we use in binary form need to be trusted for the same reasons. And Debian Reproducible Builds still has the original trusting-trust approach to contend with as well: i.e. they could bootstrap with a previously-corrupted gcc binary. The DRB website lists a Ph.D. dissertation on improving this situation, but I haven't read it, and I don't think it's been implemented in DRB: https://dwheeler.com/trusting-trust/