I get the idea but it seems clear that it will result in unmanageable spaghetti code in very little time. This model forces the developer to entangle versioning with logic. Since a big part of Temporal's value proposition is dis-entangling logic from state management and other orchestration, I expect you can see why this is a problem.

Put another way, it's a great big leak in the abstraction.

I see your point. But so far we didn't hear many complaints about this feature from the users. The main problem is in forgetting to version code that changed. But the system has protections against such cases.

It doesn't end up in spaghetti code as old branches are proactively removed after they are not needed anymore. Temporal provides APIs that allow to count number of workflows using each version.

I don't think it is a leaky abstraction as it is indeed a part of the business logic of deciding how old version of the state should become a new one. I don't think there is a generic solution that allows implicitly migrate old state to a new state on any long running computation.

You might find the concept of Edit Lenses to be useful. A good writeup is: https://www.inkandswitch.com/cambria.html

I wish it were that simple :).

A workflow is not just externally stored data with a well-defined schema. It is the computation's whole state, including threads blocked on API calls and local variables on the stack. So it is not possible to define translations between different versions the way Edit Lenses do.

So a process checkpoint? They make me anxious.

Why not assuming that you can roll it back to any previous state any time later? Temporal supports such rollbacks.