But this is always comparing apple and oranges: "theoretically, a user can completely avoid memory safety issue in Rust by never using unsafe or problematic dependencies" vs. "in practice C/C++ still often have memory safety issues".

In practice, we also still see memory safety issues also in Rust code exactly because people use "unsafe" or have a dependency that does. I also see that practical impact of memory safety issues in well-maintained C/C++ code is almost zero on my personal security (rare, often mitigated or extremely difficult to exploit). And after the LLM wave of issues is processed, this will be even less a problem. I am far more scared about supply chain issues (and I bring this up as comparison for proper risk assessment, not to move away the discussion from memory safety).

Then, theoretically, one could also make sure C/C++ have no memory safety issues. (And I have done this myself in toy programs and industry also for larger projects, so this is not even purely theory.) The languages does not fully support this yet, yes, but why does this matter so much? The language / compiler / good coding standards still support reducing memory safety issues to low levels - which is relevant, because outside of theoretical scenarios, this is what Rust also achieves in practice (and not perfection in getting rid of memory safety issues).

And then now in this thread, this argument that in C/C++ it is more difficult to achieve perfect memory safety was even used as argument against a feature that would be a step towards making this easier. This I find completely misguided.

(I am not talking about compilers bugs).