> Isn't lots of asynchronous orchestration also too complex for people?
Lots yes. Some no.
Let's take away the big words and observe what remains.
People - Western, English speaking people - draw diagrams on whiteboards and flip charts. The diagrams read from left to right, top to bottom. Usually the diagrams consist of boxes with some words on them, and arrows with some words on them.
> Orchestration is just inherently difficult to model in one's head.
For programmers, yes, for people, not so much. As long as the result is not "too busy". I.E. diagrams cannot contain too much detail. If they want to express more detail, they flip to the next blank page and draw another not-so-busy diagram. And so on. Drawing everything on a single diagram is anathema. Good powerpoint slide decks are like that. One point per slide, advance to next slide if more detail is required.
>
> Conversely, it's the most natural thing in the world for my kids to say first do this, then do that. Lots of people imagine moments in time advancing synchronously everywhere at once.
Yes. And your kids have no problem saying "while the potatoes cook, cut up the carrots". They don't invoke monads or futures or awaits to say this, they just say it. When they draw it on a whiteboard, it's pretty clear - one box branches out to two boxes. Left to right. Then, the two branches join back together into a single box. No rules. The person drawing the branches gets to say when the branches join. The toolmaker doesn't get to dictate. The toolmaker provides a recursive canvas (a flip-chart, or an erasable whiteboard) and provides the dry-erase markers. The person doing the drawing uses the tools to say what they mean.
Not everyone expresses what they mean in a good way. The people who do this well are promoted to "Architect" status, the rest don't get promoted.
> So there's a kernel of something here, but I don't think it's quite fully baked yet. Sync vs async is too blunt to be all of the answer.
In a way, yes, in a way, no. My feeling is that this is quite simple and doesn't need to be complicated further. Encapsulate units, make the units be totally independent. Function-based programming languages do only half of the job. It is trivial to do the rest of the job. Preserve time-ordering and left-to-rightness and top-to-downness. Allow composition of such units (aka LEGO-ification). Current programming languages lean solely on the LIFO meme (stack). Simply adding a LIFO meme (queue) can break out of the step-wise (synchronous) paradigm. This is nothing new - networking protocols already do this kind of thing. I think that we can push network protocol-ization down to the programming level. Easily.
Don't use one at the exclusion of the other. Use both. LIFO and FIFO. CALL/RETURN and SEND.
LIFO is good for expressing the innards of components, FIFO is good for expressing inter-component communication.
Input and output queues are good for preserving time-ordering of data arrival and data generation.
"Programming" is the whole enchilada. Innards and inter-component communication.