cool - was the rationale that having a queue of pending-producers in addition to the buffer is unnecessary complexity, and potentially a memory leak (e.g. if there's a long pending-producer queue, no consumers and close! did not clear the pending-producer queue) ?

I don't know really, but core.async has several of this "strange" behavior. I don't remembre right now the exactly one, but when I started to implement csp in promesa i looked a lot on the core async source and found many situations that probably leave at least surprising behavior or not clearly understand the proposite of some code. I guess, that if you close a channel, you still can take values from its buffer until is empty (the same as in core.async and promesa), in core.async they decided that unbuffered chanel has an implicit buffer of pending operations that works in the same way if there are buffer; but still strange, if you want buffer, just use a specific buffer

An other topic: i have in mind adding an unordered, priority based buffer implementation, this will allow create a processing queues with tasks ordered by some external priority value, any thoughts on this?

i ran my tests with promesa CSP from promesa:trunk:HEAD, including the cljs impl ...

;; cljs with promesa CSP
Ran 93 tests containing 735 assertions.
1 failures, 0 errors.

;; clj with promesa CSP
Ran 93 tests containing 731 assertions.
1 failures, 0 errors.

priority-based buffer impl sounds pretty neat, although i don't think i have a use for it atm in any of my current projects

one thing i would really like is to give channels a terminal error-state, so that once they are errored any future take will return an errored promise - i'm currently having to do error propagation by putting an error marker type on the downstream channel and then closing it normally, which works to propagate an error, but will only ever throw the error once consumer-side after which point the channel will look like it closed normally

i will think on it, it was also on my mind this, giving channels the missing piece, error handling will make them pretty universal, in the same way as completable futures are for a single value

yep. the reactive streams spec also includes an error state, which indicates it's not a crazy thing to do... i think i recall ztellman saying that he'd never needed error states in manifold, but i suspect that might be because his work was focused on hot sources - I've definitely felt the lack of error state keenly in work mainly with cold sources