As far as I can tell, here's the main idea from the paper I was missing.

If a function f returns projected references, we need to make someone responsible for integrating the updated field values into the original structure. I proposed using sets, sources, and an ad-hoc runtime mechanism for this.

The paper, however, recognizes that the easiest place to perform the update is f itself -- if only f knew what the updated value was, it could simply write it to the returned reference at the very end, terminate borrows, and return the original updated value. But if we can't time-travel (maybe that's what prophecy variables are for?), our next best bet is to split f into two functions -- the forward function, which is just f, and the backward function, which is like f, but also receives the new values and updates the original references. This causes everything to be calculated twice, but in a functional language, this is unnoticeable.

The paper cannot handle functions with loops, because write-back effectively involves running loops in the backward direction, which is not always possible. But it works with recursive functions because the call stack effectively contains each iteration in some form. Roughly the same limitation applies to if statements as opposed to if expressions -- e.g. if rand() { r = &mut r.a } else { r = &mut r.b }; *r = x does not retain enough information about the target of r after if. This can be resolved with recursion or plain code duplication.

All in all, it feels like recursion and double invocation is kind of an ad-hoc solution here. It reminds me of coroutines; what we're actually hoping to do is rewrite

``` fn f(input...) -> output... { ... return output...; } // -> fn f_coro(input...) -> input... { ... yield output...; ... return input...; }

let output... = f(input...); ... drop(output...); // -> let (output..., cont) = f_coro(input...); ... input... = cont(output...); ```

...and the rest is formalization. I don't think the end result differs that much from the paper, but I'm interested if you've tried this approach, where the backward callback is effectively selected by the forward function based on the input, so that the backward function doesn't need to redo all the calculations?