Here's my biggest question posed yet again, because the paper does not provide an answer to it: The analysis requires that all mutable references be statically proven to not alias on function entry. So how do you call a function foo(T& a, T& b) as foo(x, y) where x and y are instances of shared_ptr<T>? (The problem persists even if a and b are of different types, because a might own b or vice versa.)

This is not a contrived example. It is precisely what kept hitting us in Rust with things like @mut and we took years to figure out the best solution (RefCell/Mutex). It comes up all the time because you can't get away from RC--large programs use reference counting a lot, and even if they don't one of the major use cases of systems languages is to interoperate with GC'd or RC'd systems (dynamic languages, COM, Core Foundation) where you don't statically know anything about aliasing. Forbidding these calls statically bifurcates functions into "those callable on shared_ptr" and "those callable on owned or stack-local objects", which is unusable in practice. The only solution we found is dynamic enforcement of the aliasing rules, scoped to reference counted pointers. This indeed works, but it requires overhead. You want this overhead to be opt-in in a low-level systems language, but existing code was not written to opt into this. So C++ will need to backwards incompatibly introduce RefCell/Mutex to support this.

The bottom line is that I see a dilemma. Either C++ makes it impossible to use shared_ptr with mutable references, severely damaging usability, or it breaks backwards compatibility by making shared_ptr immutable and requiring dynamic enforcement of the borrow rules for mutable shared_ptr. Either option has huge consequences for existing C++ code.