Why "latent" is not "harmless"

The snapshot exists so a tier's verdict names one binary. A row that opts out reads whatever compiler/pascal26 is at the instant it runs. On a quiet tree that is the same file and nothing differs — which is why this has never been seen and why a byte-comparison would not find it.

It bites precisely when a rebuild lands mid-run, and that is not hypothetical here: compiler_changed_mid_run is a field testmgr publishes because the case occurs, and the auto-pin refusal gate reads it. The first opt-out was found in test-nilpy, which is where the mid-run rebuild was first observed. So the two rows most likely to be affected include the one where the phenomenon was first noticed.

The shape of the fix

Do NOT extend the regex to match $(CURDIR)/ and "$root/" by adding alternatives — that is the third copy of the same table and it will miss the fourth spelling the same way it missed these three. Two better directions:

Make the opt-out loud. Any recipe row naming compiler/pascal26 that the rewriter does NOT touch should be reported once per run, with the line number. Three rows today, so the noise is bounded, and a new spelling announces itself instead of silently opting out. This is the cheap one and it converts an invisible class into a visible list.
Normalise the spelling at the source. If the rows can all say ./$(COMPILER), the rewriter needs one pattern. Check first whether $(CURDIR)/ and "$root/" are load-bearing for the cd those rows do — .././ was, which is how this family started.

Makefile:155 is a third case and may be fine: the path is an ARGUMENT to a script, not an invocation, so rewriting it might be wrong. Decide it explicitly rather than by omission, and say which in the commit.

Provenance

frank-seven, re-testing all five spellings against the NEW pattern after 6aa50d6eb landed, having established that the fix closed the too-much mode. Not a regression from that commit — these three were skipped before it too.