This idea has a history! The reason most language research programs like this had limited success is as follows.

There are precious few programs for which a|b ~ a;b is true for all atomic programs a,b where:

| is a parallel composition operator

; is the normal sequential composition operator (defined in the completely standard way in terms of updates to a global state or heap/stack-like structure if you want to be fancy)

~ is any sort of equivalence relation on reasonable and realistic semantics.

More-over, there are precious few programs that easily decompose into parts A,B,... such that A|B ~ A;B is true for each A and B in the set of parts. You can give theoretic characterizations of this fact, and many have, but the pragmatic point is more convincing.

Associativity and even reflexivity often fail as well.

The allure of this line of thought is promising, but alas... The "just make a simple algebra and arrange your programs to fit it" research program died early on for a reason. In the context of parallel and concurrent programs, it is hard/impossible to solve the decomposition problem at the language level of abstraction.

That pretty much summarizes outcome of a big chunk of program analysis research from the 70s to early 90s in a nutshell, unfortunately.

Let me briefly illustrate using OP's example:

`a' = b + 1; b' = a + 1`

from which I've deleted the errant training semicolon (it's `1+1` not `1+1+`!)

Suppose we instead have the program:

a' = a + b + 1; b' = a + b + 1

Now, the ordering does matter! No worries, so we order.

Additionally, suppose we put these programs into an outer while(true) loop and that's our whole program. Now what have we bought ourselves? Not much.

In this case we can solve that problem by... well, by solving some sort of integer recurrence equations that give us a program without loops which we can then think about algebraically. But of course this gets difficult or impossible very fast. (And, btw, the algebra part here did not buy us much. It was solving integer recurrence equations that saved the idea in this example). We haven't even added real data structures or external state yet.

Anyways, looks like OP is building something around this idea. Good luck! I'll be curious to see how you handle loops inside of blocks that contain @'d variables with recursively defined quantities :)