Part of the discipline of writing C++ and C libraries is writing around a stable interface, that you can link against. In C++ that means using the pImpl pattern.
Which is, of course, the actual gripe we're discussing. The lack of dynamic linking is just a consequence.
This has happened and will absolutely happen again. Just being "memory safe" will not prevent protocol errors, bad IVs, preventing timing attacks, or the other subtle things involved when doing cryptography on the wider internet.
There's a huge list of tradeoffs between dynamic and static linking, and Rust is betting that in today's world, with modern tooling, internet availability, hardware speeds, and memory size, the benefits of static linking outweigh the costs. I guess time will tell
But- traditionally Linux has really leaned into the opposite approach, so it'll be interesting to see how that dissonance plays out, and whether one or both is forced to compromise, as Rust gets more embedded in the Linux ecosystem
As a Rust fan who subscribes to the classical Linux distro model (and even exclusively gets his Rust crates from there), I disagree. What you suggest comes with a cost, namely having to accept software in constant flux. To me, that cost in unacceptably big.
I write a bit more about this gripe here: https://news.ycombinator.com/item?id=32925491
(Of course the problem is technically hard, or possibly unsolvable, so I don't blame the Rust folks for its existence.)
This is one of my few big gripes with Rust too, but it should be pointed out that it's dynamic linking with other Rust code that isn't really supported. Dynamic linking with e.g. C libraries is a breeze.