From my perspective as a C++ programmer talking about “interior mutability” is a bit nebulous. I had to look up the documentation for Cell and RefCell not that long ago to figure out what it was, and my curiosity was piqued by discussion and code containing usage of Cell / RefCell , not any mention of internal mutablity. I think it would be a mistake to assume this term is in common usage in the programming community.

I think from a C++ (and non-functional) perspective it is important to distinguish external mutability as being managed at compile-time (using Rust’s borrow system) while internal mutability is a runtime construct, at least in the context of the current Rust implementation. Definitely talk about external mutability first, emphasizing the fact that it is managed and enforced at compile time. From there add internal mutability as an extension to external mutability, emphasizing the dependence on runtime management and checking. People tend to liken Rust’s borrow checker to std::unique_ptr or std::shared_ptr; I think this is probably a reasonable parallel for unique_ptr (a scoped compile-time construct), but shared_ptr is much closer to Cell<T> and internal mutability in terms of how it is implemented.

Maybe instead of saying &T is immutable in a strict sense, emphasize that it is immutable at compile time, and sort of leave the runtime distinction as an ambiguous dark cloud until you get around to explaining Cell<T> /internal mutability. Possibly even have a small section which talks about internal mutability just after external mutability without explaining the how or why until later.

I think you shouldn’t wait too long before introducing internal mutability; it seems to feature to some degree in many Rust libraries I’ve seen. It certainly needs to be introduced sooner than it is currently.