Here are the outstanding issues of SRFI 13:

8. Should we switch to unique enum objects rather than symbols?
Symbols are all distinct from one another, and are convenient to use,
but it's not possible to ask which enum-set a symbol belongs to, for it
may belong to more than one.

12. Should we stick to just comparators, or also allow equality
predicates?  SRFI 114 provides comparators for `eq?`, `eqv?`, `equal?`,
`string=?`, and `string-ci=?`, which are the Big Five.  Hash tables need
to accept equality predicates for backward compatibility, but there is
no real compatibility issue for sets.

13. Should we switch to six libraries (sets, bags, integer sets,
character sets, enum sets, and set-bag conversion), or stick with a single
library? (This is not about dividing the SRFI itself.)  The only reason
to do this would be to minimize namespace pollution and load space:
if you don't need bags or charsets, you wouldn't have to have them.
On the other hand, the whole package is only about 2 KLOC.

14. Should we add a cursor API similar to SRFI 14's?  This would allow
stepping through the elements in a fixed order.  It wouldn't make much
sense for general sets or bags, but might be handy for character sets
(via SRFI 14), integer sets, and enum sets.

15. Should we add comparators that allow all the set types to be compared?
That would allow sets of sets, bags of sets, sets of bags, etc.
There is no natural ordering of sets, unfortunately; lexicographical
order wouldn't make very much sense.  If anyone has ideas about this,
I look forward to hearing them.

--
Overhead, without any fuss, the stars were going out.
        --Arthur C. Clarke, "The Nine Billion Names of God"
                John Cowan <xxxxxx@ccil.org>