I was inspired to write this after re-reading <
https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/>, and I'll defer to it for more detailed arguments, though it does not mention transactions.
The basic notion here is that the structure of your program should reflect the way in which you interact with things. Unrestricted gotos are bad because it's better to think in terms of structured conditionals and loops instead. Some efficiency is lost in bad cases, but it is much easier to be sure that the conditional or iterated parts of the code are contained in a single scope, with all parts adjacent modulo procedure calls, and even then the dynamic extent of the call is within the dynamic extent of the conditional or loop.
The article above argues that the same should be done with coroutines/futures/threads: they can be created any time within the scope (technically, the dynamic extent) of a novel construct, and must all have terminated before the construct ends. Similar cases are the Scheme procedures call-with-port, call-with-input-file, call-with-current-input, etc. These are much easier to reason about and use than unstructured open-{in,out}put-{file,string,bytevector} and close-port operations. Another is the C# `using` and the Python `with` syntax, which extend the idea of those port procedures to structure the eager disposal of objects.
Well, you see where this is going. I think we should flush the unstructured okvs-{begin,commit,abort}-transaction procedures from the SRFI in favor of okvs-in-transaction only. This means that in the simple case all operations done in one transaction appear in one procedure; the fact that this procedure takes a transaction object means that the dynamic extent of a transaction can be extended to other procedures as needed, just as conditionals and loops can call procedures inside their bodies. But what can't happen is beginning a transaction in one scope and closing it in another, which is always going to be error-prone.
Comments?