> So how does Rust prevent something like this throughout the code base

In some sense, it doesn't. But in another sense, you can't just throw unsafe around things. Unsafe doesn't turn off checks. Unsafe adds new unchecked constructs. This means you can't have written a bunch of code, run into errors, and just toss unsafe {} around it. You'd have to actually re-write it with unsafe constructs in the first place.

You can very much do that, if you want. But it's not a trivial escape hatch.

I understand the "unsafe" construct on the technical level, but thanks for clarification nevertheless.

My point was that, with "unsafe", Rust provides a technical construct which allows to carry over some negative development styles, possible in the C(++) world, without friction (if wanted). And from the list I linked, there seems to be a lot of momentum for this kind of behaviour in certain industries.

   You'd have to actually re-write it with unsafe constructs in the first place.

This is what I think would happen, and tried to describe. Someone trying to implement a feature, failing with safe mode and resorting to "unsafe" from scratch, just to get it done.

So it stays the way it is, i.e. I can't buy the "possible fail places are easily grepable" argument.

Yes, in theory that could happen. In practice, we don’t see it happening. Doesn’t mean it can’t, but time will tell.

it doesn't. if such code passes peer review, it's their problem. you absolutely need buy-in from devs that the borrow checker is there to help you and save time for your future self.