I'm not sure the "distribution" would be all that helpful. A single compiler that does some parallel work and collect the results of that work in a list in ord

I'm not sure the "distribution" would be all that helpful. A single compiler that does some parallel work and collect the results of that work in a list in order of completion (and similar) are probably the most common cause of non-determinism. Given that, your chromatograph would be mostly "determined" by the source code's peculiarities, instead of the offending compiler itself. (E.g. I have n classes a compiler would process in parallel, so given a single point of timing non-determinism n! different combinations could possibly exist (assuming they all cause a different outputs). The only information I could conclude from such a distribution is that there is a common sequence of completing tasks). But your idea is cool, and simply reporting back non-matching local builds would be helpful (I believe the binary property of whether a different output could be built is the only relevant fact) -- also, if we were to mark a package as non-reproducible, we could recursively mark everything else that has it as a (transitive) input.