The transduce form can very well be replaced by generators, although I doubt you will get the same performance out of it in most schemes where call/cc is expensive.
Only the most general generator constructor, make-coroutine-generator, uses call/cc. All the others use mutable state only, as do all the accumulators (reducers in your terms).
This matters very little when collections are transformed, where a lazy approach also means no intermediate collections, but the general transformation side is harder to imagine using generators.
You set up nested calls, with a generator constructor on the inside invoked by a generator operation, which is invoked by another, ... which is either pulled from by the program or accumulated using an accumulator.
I'm now definitely going to create yet another SRFI that is upward compatible with 158 (which is upward compatible with 121), adding generator analogues of some of your procedures plus the three mentioned above. I think the chain procedure will in effect construct the nested calls described above, so it takes a generator constructor as the first argument and generator operations as the rest of the arguments and runs them left to right (left = inside, right = outside). Perhaps the last argument will be an accumulator, or I may keep that separate. The tricky bit is the arguments to be passed to the intermediate generator operators. To handle these nicely, it may have to be a macro.
Detailed review of SRFI 171 to follow.