retirementReAssertion

Three of this binding's samples, in causal order, spelling out the shape a retiring type is easiest to get wrong on: one that asserts something, a later one that retires it, and a later one still that re-asserts it — together with the predicate that reads that "something" off the binding's public value surface.

null — the default — goes with retirementIsMeaningful = false.

Why the binding has to declare this rather than the suite deriving it. Retirement is not expressible in the join-semilattice algebra: a removal is more information, so s → s.remove(k) moves up exactly as s → s.add(k) does, and s ⊔ s.remove(k) == s.remove(k) holds either way. Nothing the suite can compute from Quilted.piece and == separates the two — which is precisely why the three states have to arrive with RetirementReAssertion.shows attached, and why naming them alone was not enough (#2157).

The re-asserted value must be one the retired value does not dominate. If it is simply "different" — a larger count under the same author — a join that drops the retired contribution lands on the same value as one that keeps it, and the shape proves nothing. Measured against the pre-#2099 ORMap: re-asserting GCounter.of(a to 1L) or GCounter.of(a to 2L) after a retired GCounter.of(a to 1L) finds 0 associativity violations; re-asserting under a different author finds 12. That last part is a judgement the suite still cannot check — see samplesReAssertAfterRetirement.