That's an interesting (and correct!) objection — in stats terms, it's the choice between having false positives (your type checker rejects some valid programs) vs. false negatives (Valgrind didn't catch these cases).

If you're writing safety-critical software though, being forced to restructure your code to satisfy the type checker (which, in this case, is kind of a simple proof assistant) seems like a sane tradeoff.

You're talking about completeness: the borrow checker rejects some valid programs (any type system will do that). Soundness is talking about catching incorrect programs; the borrowck doesn't allow a single invalid program through.

Valgrind is not a static analyzer, You should use some C static analyzers to compare the false positive rate. You can use various dynamic instrumentation based tool to detect other classes of bugs that are not caught by the borrow checker in Rust.

Valgrind only catches the errors that your test suite triggers.