or are just imagining something incorrectly,

You do not have to take my word for it. Read the literature.

As a starting point, read this paragraph that talks of "no longer have[ing] the synchronous "lockstep" execution of Chapter 4". Then go back and read Chapter 4 in its entirety and see if it doesn't fit more or less exactly with your proposed "converts the asynchronous commands from the threads or forks into a single synchronous stream"?

And consider that your half-remembered, half-understandings of things that you encountered 20 years ago, are probably less reliable than things I read in detail about last month or last year or the year before.

do you think IBM transaction monitors would have survived on the market for years if this were true?

Firstly, the requirements of a pseudo-concurrent virtual machine time-sharing system running on 70s/80s single core hardware with clock speeds in the low 10s of megahertz are quite different to those of true shared-state concurrency of today's multi-threaded, multi-core hardware running at 2 or 3 gigahertz. IBM know this and moved on long ago. If you need more explanation of that, again, read the literature.

Secondly, the single biggest killer of performance in concurrent systems, shared-state or otherwise, is synchronisation. Full stop. It's an indisputable, very well documented fact known by anyone who has read anything relevant in the past 10 years or more. To achieve best (or even good) performance on concurrent systems, you must avoid synchronisation like it was the plague.

To base your inter-TOE communications mechanism around the sole concept of "converts the asynchronous commands from the threads or forks into a single synchronous stream" is disastrous. You have effectively created a single linear flow program, except you've thrown a significantly costly context switch between each step of your serialised stream.

Don't take my word for it, but don't make it up as you go along. Read the literature. It is out there.