Well, it's good that we've gotten to the point of us both agreeing that what is Nock designed to do is novel and useful. It's certainly up in the air whether Nock will succeed in doing it, but I think it has a better chance of doing it than systems that don't even try.
I want to point out an error in your reasoning here, though, which results in you seriously underestimating the importance of Nock's goal:
> you're writing in some other language which… [i]s either frozen and you accept the potential insecurity, or it's patchable and you accept the potential nonreproducibility
Suppose I gather some data, do some statistical predictions based on it, plot the results, write them up, and publish the whole bundle as a set of programs for some reproducible computing system, including a build script that rebuilds the article from the source text, the observation data, the statistical code, and so on, with a secure hash of the whole thing. I don't even need to include a PNG of the plot in the bundle — anyone in the future, whether in 02021, 02030, 03020, or 12020, can recompute that bitwise-identical plot from the source data. Moreover, if I made an error in my analysis — either due to a software bug or for any other reason — they can reproduce that error.
Suppose the statistical code is compiled from a Julia-like language to bytecode for the reproducible VM. To achieve reproducibility, I could include the compiled bytecode in the bundle, but a better solution is to include the version of the compiler that I was using. That way, someone who wants to criticize my conclusions in the future can recompile my statistical source code with a new version of the compiler to see if my results were due to a compiler bug. Lacking that, they can reproduce my incorrect results, and they can recompile my source with a new compiler and get a different executable that produces different results, but it will be harder to tell why they were different.
In neither case, though, does fixing compiler bugs destroy the reproducibility of the computation, as you say it does. The executable compiled by the buggy compiler will continue to produce unchanged results on future versions of the VM, as long as they are not buggy. Shoving the problem up one level makes it into a completely different kind of problem with completely different implications.
I don't think there's any other system out there that attempts to deliver this level of reproducibility today, although some video game emulators come close. I'm probably going to have to write one myself, because I'm not convinced Nock is going to achieve it. Substantial parts of Dercuano and BubbleOS are steps toward this goal.
I want to point out an error in your reasoning here, though, which results in you seriously underestimating the importance of Nock's goal:
> you're writing in some other language which… [i]s either frozen and you accept the potential insecurity, or it's patchable and you accept the potential nonreproducibility
Suppose I gather some data, do some statistical predictions based on it, plot the results, write them up, and publish the whole bundle as a set of programs for some reproducible computing system, including a build script that rebuilds the article from the source text, the observation data, the statistical code, and so on, with a secure hash of the whole thing. I don't even need to include a PNG of the plot in the bundle — anyone in the future, whether in 02021, 02030, 03020, or 12020, can recompute that bitwise-identical plot from the source data. Moreover, if I made an error in my analysis — either due to a software bug or for any other reason — they can reproduce that error.
Suppose the statistical code is compiled from a Julia-like language to bytecode for the reproducible VM. To achieve reproducibility, I could include the compiled bytecode in the bundle, but a better solution is to include the version of the compiler that I was using. That way, someone who wants to criticize my conclusions in the future can recompile my statistical source code with a new version of the compiler to see if my results were due to a compiler bug. Lacking that, they can reproduce my incorrect results, and they can recompile my source with a new compiler and get a different executable that produces different results, but it will be harder to tell why they were different.
In neither case, though, does fixing compiler bugs destroy the reproducibility of the computation, as you say it does. The executable compiled by the buggy compiler will continue to produce unchanged results on future versions of the VM, as long as they are not buggy. Shoving the problem up one level makes it into a completely different kind of problem with completely different implications.
I don't think there's any other system out there that attempts to deliver this level of reproducibility today, although some video game emulators come close. I'm probably going to have to write one myself, because I'm not convinced Nock is going to achieve it. Substantial parts of Dercuano and BubbleOS are steps toward this goal.