It seems to me that there are real obstacles to that; since the propagation of messages from one channel to another requires a separate 'take' and 'put', there's some halting problem-style obstacles to figuring out the causality of how messages are propagated.

You can maybe create propagation operators that make these relationships explicit, but that would require either eschewing the bare take/put methods, or making sure the take/put behavior is in sync with whatever metadata you use to describe it.

That's the kind of thing I was thinking about. The topology in lamina is described by data whereas in core.async it's described by code. I'll have to experiment more with both and see where the tradeoffs lie.

It seems possible to me to build the lamina style topologies on top of core.async.

In fact, that seems preferable to me.