Libsecp256k1 implements a variant of ECDSA used by the Bitcoin system (and many other things now) which eliminates malleability by requiring s to be in the lower half of its range. Callers that need compatible (but vulnerable...) behaviour are instructed by the documentation to call a provided normalize function on signatures before validating them.

Someone opened an issue reporting that secp256k1 ecdsa sha256 test case 218 fails. I confirmed that this failure is due exclusively to this restriction.

You can expect other secp256k1 implementations to implement similar things as this behaviour is required for consensus consistency with Bitcoin, so it might be useful to avoid gratuitously triggering this incompatibility, and flag tests that necessarily do so (e.g. because they are intentionally trying to use high S values).

Thanks for the interesting work. Although we have very extensive testing already, I think a diverse test cases created by a different set of minds will be a valuable addition to our testing arsenal.

You may be interested in a different test strategy, implemented by our "exhaustive" tests based on the observation the virtually all code in an ECC library is independent of b in the curve equation (usually only point decompression/validation depends on it). We use this fact to allow a test harness to build an alternative version of the library that operates using a different curve equation on a small sgroup (e.g. of size 43) where we can do things like exhaustively test group operations. We've shown this test to be effective at detecting some real but otherwise incredibly hard to detect bugs, such as cases of incorrectly handled group law incompleteness. As a result it might be interesting to publish vectors for these easily tested degenerate groups.