As I've already mentioned, I have some concerns about the usability and
extensibility of the interfaces defined in the SRFI. I would feel more
comfortable if there were some examples of the interfaces in actual use.

Examples of implementing collections:

    grab-bag        enumerates contents in random order
    fibonacci       an infinite sequence of numbers
    hash-table      a dictionary implemented with a hash table
    red-black-tree  likewise, but with an ordered tree structure

I'd like to see at least two collections for each type: one "ordinary"
and one "interesting" collection. For example, an "ordinary" bag just
stores values and enumerates them in arbitrary order. An "interesting"
bag is something like the grab-bag.

I'd also like to see some examples of the collections in use, to show
whether the interfaces are actually useful and intuitive. A good example
would be a function which sorts all the elements of a bag.

Basically, I'm worried by the lack of a usability design goal (indeed,
I've seen just the opposite), and I've seen too may examples of
incompatible definitions. While redefining the original "vector-set!"
may work well on the Scheme implementation you're using, it would work
horribly on PLT Scheme. (SRFI-44 is not alone there. SRFI-1 has a few
interfaces which just don't work on PLT.)

I find it unacceptable to excuse those issues with claims like, "It's
just a SRFI. Implementors don't need to use it," and "If programmers use
it wrong, they deserve what they get," and "Prior art isn't important."
That's a great way to develop something that *won't* get used.

Basically, I'm asking whether you've eaten enough of your own dogfood to
know what it tastes like. If not, you may want to hold off on releasing
the SRFI to know whether it's something people will actually *want* to
use.
--
Bradd W. Szonye
http://www.szonye.com/bradd