You may be correct that the ‘fixing letrec reloaded’ algorithm, unmodified, might have these issues. However, a compiler can trivially recognize an optimization of (let ((foo (begin <expr> (lambda ...)))) …) to make foo be ‘well known’ after the transformation of letrec* to let, fix, and set! is completed.

I don’t want to compromise the semantics (I don’t see a reason to forbid returning multiple times to the continuation of an expression, as long as any following definition is not reached and completely re-evaluated) for an optimization which seems possible anyway — and which I think would not be needed in the vast majority of use cases of SRFI 245 anyway.

Daphne