This should not be a surprise at all given the amount of soundness bugs that were collected in the Rust compiler but no-one cared. [0]

EDIT: I don’t even think HN cared either up until now. If you search this paper on HN, guess who posted it?

Lets hope that this will be the only occurrence of soundness bugs in Rust and perhaps it needs a tiny disclaimer on claims of “safety guarantees”.

[0] https://arxiv.org/abs/2608.28713

It looks like 18 of the 30 issues listed in table 4 had already been fixed when that paper was released, and there is activity in most of the rest. One was recently flagged as being fixed by -Znext-solver, and another has the submitter write that it is fixed, but the issue is not closed. And that's before you consider the impact of the individual issues; how many of the remaining issues impact "real" code?

So I don't think it's fair to claim that "no-one cared".

I don't think "no one cared" is a fair characterisation. The paper doesn't support this conclusion, and from experience I'd say that the two difficulties in fixing unsoundness are doing so without breaking existing code (Rust guarantees stability unless the code is unsound, and introducing previously missing checks can cause sound code to stop compiling, which is a problem if it occurs often) and doing so in a reliable way that can be supported long-term. Rust is currently in the progress of stabilizing next-solver and Polonius, both of which fix multiple long-standing bugs and have been worked on for years now due to intrinsic complexity, performance considerations, compatibility issues, etc. It's not that no one cares, it's just that this stuff is hard and takes time.