FAQ: Why isn’t mutable a subtype of immutable, or vice versa?

This difference is similar to interior mutability in Rust: &Cell<T> and &mut Cell<T> can both modify the inner T despite only the latter using &mut. That's why the preferred names for & and &mut are shared reference and exclusive reference instead of immutable/mutable.

Because of interior mutability, Rust needs an extra layer of requirements to guarantee thread-safety: the Sync and Send traits limit shared memory access to thread-safe types like Mutex<T> or atomics.

In Haskell mutability when modeled as a monad, this just means that “a” and “m a” are not in a sub typing relation.

So, since all memory is mutable as a ground fact, and immutability is a contract that has to be proved for an object, it makes sense that Rust (as a popular example of an approach) goes the way of focusing on locating mutability not on the value itself, but on its reference, since at a lower level, proving that a value is not going to mutate has to do with proving/enforcing a contract with all code that references that value.

I was asked effectively this exact question about a year ago, and ended up writing a blog post about it. Mutability is no friend of subtyping indeed.