I do not believe this is correct. It sounds likely to be correct for the limited case of reading memory through this pointer. But it does not hold for calling methods, including calling Drop glue when mutating the value through this pointer.

The reason being, method calls through this pointer use the static type of the pointee to resolve the monomorphized function to invoke (this includes calling Drop glue). But you've just defined mutation here as allowing a `&Ai` pointer to actually point to a `Bi` instance, which is a distinct type. Calling methods based on the `Ai` type but with a `Bi` instance is obviously incorrect.

Now as to whether this can trigger a segfault without going to `unsafe` code at some point, I don't know. But this definition of mutability makes it impossible to wrap `unsafe` in a safe API, because that safe API relies on the type system accurately representing the types involved. As a trivial example, this definition means that `Vec<u8>` and `Vec<StrBuf>` are considered *layout-identical* (you're not actually precise here, but I'm assuming `*T` and `*U` are *layout-identical*, because they're both just raw pointers; since you're following the C model here I'm pretty sure C considers them *layout-identical*). Which means that if I can use mutation to replace a `Vec<u8>` with a `Vec<StrBuf>`, my existing `&Vec<u8>` reference matches your rules, and yet I'll crash horribly if I actually try and do anything with it.