The file claimed capi_<goos>_<goarch>.go are "the source-of-truth files ccgo
consults when linking against this libc" and told contributors to add every new
Xfoo to them. Both are wrong, and the second is busywork.

They are leftovers. Very old ccgo versions consulted them years ago; they are
kept only so existing code in the wild does not break, and that is their entire
purpose. Current ccgo discovers this libc's API by parsing the libc sources.
Most were last touched in 2023 (capi_windows_amd64.go 2023-02-22,
capi_linux_amd64.go 2023-06-08), so they are years out of date.

Also flags the specific trap, because they look authoritative sitting next to
the code: being stale UNIFORMLY, they compare equal across libc versions that
genuinely differ, so "the capi files are identical, therefore libc is not the
variable" is a guaranteed false negative. That inference was used as a
load-bearing step while diagnosing a ccgo/mingw setjmp arity mismatch in
modernc.org/wa2c and sent the investigation the wrong way; the answer had to
come from grepping the real func X... definitions.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

C keeps every jump buffer of a live frame valid and lets a longjmp target
any of them. This package kept armed buffers on a stack and Longjmp
required its target on top, so jumping from an inner setjmp region straight
to an outer one panicked "unsupported setjmp/longjmp usage" where C runs
the outer catch.

Longjmp now disarms its target wherever it sits, and LongjmpRetval carries
that target rather than only the value setjmp must appear to return. The
generated code needs the target: a panic unwinds through every region
between the longjmp and its destination, so each compares the buffer named
in the value with the one it armed and, unless they are equal, disarms its
own and re-panics, leaving the value for the region it was meant for. Of
two regions sharing a buffer the innermost is disarmed, which is the one C
resumes at. PopJumpBuffer stays strict, regions still leave in the order
they were entered.

This needs a ccgo new enough to emit that comparison. Code generated by an
older one no longer compiles, LongjmpRetval having become a struct, which
is the intended outcome: it refuses to build instead of building and then
resuming at the wrong setjmp. There is no backward compatible way to make
the fix, deciding which region a longjmp belongs to needs information the
old panic value did not carry.

The package documentation and the README say so loudly, and say why the
version numbers of this package do not mean what semver says they mean.
That was already documented but sat in a comment detached from the package
clause, where go doc never rendered it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>