I find this SRFI very interesting from a user perspective.  I have
noted below the items the confused me a bit, at least for a while.
Sorry for the long message.

  * In the description of make-coroutine-generator, should the
    occurrences of 'generate' (in text and code) be
    'make-coroutine-generator' instead?

  * In the examples just before make-bits-generator, shouldn't the
    call

    (generator->list (make-reverse-vector-generator '#(a b c d e) 2))

    yield (e d c) instead of (e d c b)?

    Also nearby, the use of #f as the start argument seems intuitively
    clear but that usage is not explicitly mentioned.

  * (minor) In the description of gconcatenate, the last sentence
    before the code is probably OK but it took me a couple of reads to
    check possible interpretations.  I am interpreting it as: each
    returned generator will be tail-called until it returns the eof
    object before moving to the next.

  * In the description of gmerge/gunion/gintersection, I'm a bit
    unclear on what exactly a caller can expect if the inputs are not
    sorted as indicated.  Is it considered an error (as in undefined
    results)?  The description says only that the result won't be
    ordered, seeming to suggest other properties will still be
    satisfied.  For example, would a gunion still remove duplicates?
    Intuitively, I suspect the answer should be no.

  * It is probably something obvious, but why isn't generator-collect
    called generator-map (similar to gfold/generator-fold)?

  * (minor) The motivation for, and efficiency promise if any, of
    gfilter-map is unclear to me.

  * (minor) Given the examples elsewhere, an example for
    gbuffer-filter may make its use clearer.  (I found one in
    generators-test.scm.)

  * Is (gpairs car-gen cdr-gen) equivalent to
    (gmap cons car-gen cdr-gen)?

  * In the description of glists, 'k' seems undefined.

    Also, the behavior when sizer is a generator is not explicitly
    mentioned, though an intuitive interpretation is easy to guess
    (and my guess matched the test in generators-test.scm).

  * For gindex, is it correct that it is not an error for index-gen to
    generate indices >= the number of items returned by (a finite)
    value-gen?

  * Question similar to the above for gnth-value, generator-nth: n >=
    number of items is OK?

  * The example for gnth-value seems to be missing the 'n' argument.
    I am guessing that argument should be 2 based on the result
    there.  Is it true that the first element of gen is always
    returned?

  * For generator-last, the behavior for infinite generators seems
    obvious, but given the "Be careful..." comments for some earlier
    procedures, it may make sense to add a similar note here.

  * Similar to above, for

    (generator-find (lambda (x) #f) infinite-gen)

    Perhaps a blanket comment somewhere may be better than the
    individual ones for such cases.  The very first sentence of the
    section does indicate "consume all the values" so  perhaps it is
    fine, but it took me a couple of parses (may be just me!):

     all (the values of the generator passed to them) v.

     (all the values) of (the generator passed to them).

   Only the first makes sense for generator->list, so my confusion was
   quickly resolved.

Regards,

-chaw