&gt; there&#x27;s no concurrency guarantee.<p>Doesn&#x27;t even have to do with concurrency. This leads to iterator invalidation and many other problems in single threaded code. In fact, Rust&#x27;s &quot;standard&quot; concurrency guarantee (with regular, non-scoped threads) doesn&#x27;t deal with the mutable aliasing rule; it works with the ownership rule more or less exclusively. Even if mutable aliasing was allowed in Rust, you could still build the same safe threading system assuming that borrows are still scoped[1].<p>The mutable-alias guarantee is more of a &quot;don&#x27;t let the rug be pulled out from under me&quot;. While this is something that&#x27;s more obviously a problem in threaded situations where a mutation from a different thread can pull the rug out from under you, a function call in complex code that mutably aliases can cause the same issue. The classic example of this is iterator invalidation; but it works with any type which contains a variable amount&#x2F;type of things, and severe logical (non-memory-safety) issues can be caused with anything with invariants.<p>See: <a href="http:&#x2F;&#x2F;manishearth.github.io&#x2F;blog&#x2F;2015&#x2F;05&#x2F;17&#x2F;the-problem-with-shared-mutability&#x2F;" rel="nofollow">http:&#x2F;&#x2F;manishearth.github.io&#x2F;blog&#x2F;2015&#x2F;05&#x2F;17&#x2F;the-problem-wit...</a><p>[1]: When I say &quot;safe&quot;, I&#x27;m assuming that in this situation (the lack of rules against) mutable aliasing itself isn&#x27;t causing any unsafety elsewhere that transitively leaks down and causes thread safety to go kablooey. As such it&#x27;s a necessary and mostly sufficient system of rules; removing one rule will probably make the whole house tumble. However, the point was that Rust&#x27;s thread safety doesn&#x27;t <i>directly</i> derive from the mutable aliasing rule.