same here wrt recovering files from dying disks, it's a lifesaver.

Tom DeMarco wrote a book "Slack" about precisely this.

after the freeze lifts, you also have multiple contributors dumping large PRs at the same time, missing out on the progressive integration that happens otherwise. This makes it difficult to figure out the cause of regression (think bisect but with large commits).

Code freezes like this are worst when there is no individual branching capability or local revision control, because that guarantees large commits.

my anecdata is that I have always filed manually by myself, but every time had a small adjustment made by the IRS... indeed filing a correct return the 1st time seems close to impossible.

is there a reference for the USSR shooting an SR-71 down?

There is no reference for this, because it never happened.

this is a beautiful zeugma you have here.

This is a re-discovery of https://en.wikipedia.org/wiki/Thomas_J._Allen 's work, everything old is new again!

This topic definately resonates with Thomas Allen's Managing the flow of technology (he was a great prof and all-around nice human being).

which new feature are not supported?

it's funny because I have seen the opposite. Engineer: "it crashed because it dereferenced a null pointer" boss: "add null pointer checks everywhere!"

... and because it used "if" instead of "assert", it made the null pointer arg a valid argument, making it a tolerable state of the running software, which displaced the locus of crashes far from the source of the issue. Moral of the story, use "assert" to make it crash as early as possible and debug THAT. You want to restrict the representable states in the software, not expand them by adding null checks everywhere.