The borrow checker is solid.
The communication with it, is a UX fail.
As indicative by the tutorials that write pseudo code to try to teach you how it works using named scopes.
By now, I get how it works but it's hard to predict in a when you're not exactly sure how to solve certain technical issues, or even how the final design of an API of several modules will look like.
Forcing you go back and forth between lifetimes, implementations and what not. two steps forward, eleven back.
It's a failure that the borrow checker does not adapt to what I am trying to achieve instead of telling me it's impossible - when I am very much aware, it's possible.
Ideas: Figure out what variations of smart pointers and mutexes will work in combination to do what I am trying to achieve and make it happen - this essentially gets rid of the borrow checker as your code becomes reference counted instead of compile error. Performance and execution becomes unpredictable as you have no idea what's going to happen once you execute.
Same as above but instead of altering execution of code offer syntactic sugar to allow me to convert references to ARC/RC/RwLock - the same way Swift offers ? as shorthand for Optional<T> and ! for explicit unwrap.
It should be easy to convert a row of code to ARC without sweat.
This way the execution is still predictable as code has pre-defined execution.
Go back to the drawing board regarding the language used between developer and borrow checker to express intent. I haven no idea how to improve this. Acknowledging it's a UX failure is the first step. Failure is harsh, but it was a good start of a way to deal with the Borrow Checker. But it needs to be improved to the point where there can be no situation where the programmer can guarantee something works and the Borrow Checker disagree - barring any false positives of course.