an expanding transducer is allowed to put more things in a fixed buffer than the buffer size (otherwise there would be no place else to put them)

if you want more laziness than that, use the transducer in a process and put to the channel, rather than putting it in the channel itself

alexmiller: Thanks for answering, Alex. I'm aware of that, but this is different. I'm OK with a buffer growing slightly overboard if the transducer returned a bigger collection; but because of this bug the size of the buffer can grow infinitely even though the transcducer returns small chunks

I filed a bug report for this http://dev.clojure.org/jira/browse/ASYNC-178, there is also a SO question addressing the same thing http://stackoverflow.com/questions/37953401/where-is-the-memory-leak-when-mapcat-breaks-backpressure-in-core-async

I believe, not checking for buffer fullness before applying the first pending put! is an optimization/assumption from a pre-transducer era. The code assumes that since a take! was just executed, there is a room for a pending put! to apply; but that might not be the case with expanding transducers — the buffer might still be full from the previous put.