That's not the RnRS convention; cf. "abelian group".

OK.

> make-for-each-generator: obj may be any kind of "collection" but AFAICT
> that term doesn't have a precise meaning here.

No, it doesn't.

OK, so this should be explicitly defined somewhere right? A programmer needs to know what data types they may safely assume will work. I imagine that for the purposes of this SRFI, "collection" may be any of list, vector, bytevector, string, or generator.

> gmerge, gunion, gintersection: The description talks about order but is
> unclear on whether it means increasing or decreasing order. How about
> saying "elements in strict increasing order according to a SRFI 114
> comparator". The "strict" qualifier implies there are no duplicates in the
> input.

Increasing order, yes. I see no reason to forbid duplicates particularly.

Well if a sequence has duplicates then it isn't really a mathematical set, and the conventional definition of set union, etc. does not work. It's then unclear whether these are actually multiset operations, where duplicates should be retained in the output; or whether they are set operations, and duplicates should be filtered out of input before performing the conventional set operations.

A less important consideration is that handling duplicates takes some effort, so these procedures can be faster if they are free to assume that inputs have no duplicates.

Regards,

Kevin