(Hello from Reddit.)
FWIW, the most recent brainstorming that I am aware of was in this thread: Blog post: View types for Rust - language design - Rust Internals
I don't mean to nitpick, but "constantly refactoring their code" is exactly what is meant by "rapid iteration" in game development. It might be worth clarifying that the kind of refactoring being referred to is strictly the kind of refactoring that is only necessary for proving disjointness to the borrow checker.
One thing about this proposal (and similar proposals) that concerns me is how to teach it to Rustaceans. By opting-in to partially borrowing self, the method can only receive the specified fields of Self. This method is unable to call any other Self method that receives a nonintersecting set of fields (and their associated "access types").
It seems that this is the case but, given the fact that I am currently having trouble articulating the concern, it makes me wonder how well it can be documented. And what else can be done to avoid the inevitable need to extend its capabilities as users need more and more coarse-grained access to fields across method call boundaries.
In well-contained cases like the examples provided, specifically the ones that are capable of being factored out to standalone functions, this would be a welcomed ergonomics addition to the language.
Specifically, the point made about breaking encapsulation ("niceness 1" in your older presentation) to work around the issue is a weakness in Rust today. There are clear benefits to doing something, anything about it.