[foldr]

>I find it a little unsatisfying that to orchestrate multiple sequences we might just defer to some complicated parts of the runtime system like "locks" and "threads", written in C :(

Ok, sure, but that's how IO Haskell in Haskell actually works. There's arguably a principled reason for that. The IO monad is there to solve a problem that's particular to lazy languages: that it's difficult to reason about the order of evaluation and hence of side effects. That's conceptually completely different from the problems raised by concurrency, which are pretty much the same regardless of whether your programming language uses strict evaluation or lazy evaluation. Fundamentally, there is no sane way for >> to guarantee that no other thread within the process is competing for the same resource. >> can't know about every resource out there. Its instance for (IO a) can, however, make real guarantees about evaluation order, without knowing anything about what various IO actions are actually doing.

One can come up with all sorts of schemes for concurrency combinators (and Haskell has no monopoly on defining combinator libraries), but in the end, to avoid two threads writing to stdout at the same time, there is going to have to be some code somewhere that acquires a lock on a file handle. That code has to live in the relevant library functions, not in the implementations of the combinators.