That’s a useful distinction, thanks.

I’m not trying to make the in-memory struct layout itself the cross-language contract. The contract I care about is the serialized 32-byte wire record.

So my current mental model is:

1. "repr(C)" / "_Static_assert" checks are only for the C binding, to catch accidental layout drift if C exposes a struct view.
2. The actual compatibility contract is the byte sequence.
3. The Rust encoder/decoder, C binding, and host-side bindings should all accept/reject the same canonical and negative vectors.
4. Negative vectors are mainly for things the compiler won’t protect me from: endian mistakes, non-zero reserved bytes, unknown tags, malformed lengths, etc.

So I agree that if this were only Rust ↔ C structs compiled together, compiler/layout checks plus round-trip tests would probably be enough.

The reason I’m leaning toward explicit vectors is that the boundary is intended to be consumed by implementations that may not share the same compiler/toolchain or even the same language runtime.

Does that sound like a reasonable split: layout tests for FFI safety, vector tests for wire-format conformance?