You can think of it as the rather classic "Vec of struct + numeric IDs" that is used a lot e.g. in Rust to represent complex graph-like structures.
This combined with bound checking is absolutely memory safe. It has a bunch of correctness issue that can arise due to index confusion but those are not safety issues. When combined with some kind of generational counters those correctness issue also go away but are only caught at runtime not at compile time (and they incur a runtime cost).
Rust's memory safety is about avoiding liveness issues (that become type confusions since all memory allocators will reuse memory for different types), nothing more, nothing less.
there are not memory safety issues. But they definitely can lead to security issues with some sort of confused deputy attack.
For example a capability based system that relied on just this form of memory safety would be pointless.
Of course this can be mitigated by adding version counters to objects and object selectors.
If you have an array of objects of the same type and you just pick the wrong one, then the data still has to be a valid bit pattern. Yes it might still be a security bug, but it's much less likely because you aren't completely subverting the language.
Surely you don't think all bugs are the same because they are all bugs?
To begin with, the whole point of classes is to maintain invariants. Guaranteeing that a location in memory matches the valid bit patterns of its members is far from sufficient.
Obviously. I never said otherwise. What's your point?
If a language is merely type-safe, then it might be OK to silently replace a value with a different one of the same type, sure, fine. Who cares if the program transmits the wrong message to the wrong recipient as long as it's definitely some message and some recipient?
But a value-safe language, I suggest, is one that doesn't pull this kind of switcheroo.