With all due respect, this late in the SRFI's stage (nearly three
months overdue for the allowed draft period), we can't really be making
such drastic changes.  The vast bulk of the SRFI was agreed upon through
long discussions both on this list and in issue related discussions on
the #scheme irc channel (for which logs are available).  Your proposal
makes several changes against the grain of goals raised by other (now
lurking) list posters.
   First, the linear-update/purely mutable distinction is absent.
Secondly, you allow for collections to behave as more than one type at
once.  This isn't forbidden in the current wording, but probably should
be.  This might be a useful extension, but it complicates implementation
as it blurs type distinctions, and has similar effects on semantics
(which you try and reconcile in your succeeding posts).
   I see your concerns related to R5RS compatibility, but your solutions
again conflict with the goals of supporting functional, linear-update,
and purely mutable datastructures.  The procedures which arise out of
SRFI-44 aren't meant to describe behavior in R5RS, but to show how R5RS
datastructures would behave in the context of SRFI-44.  In fact,
implementations may choose not to implement the concrete collections
defined by the SRFI (i.e. not implement SRFI-44).  The primary goal is
to provide a framework for future datastructures.
   Its still worthwhile to correct major problems with the SRFI at this
stage (such as the problems with dictionary equivalence).  But
stylistic changes of this magnitude mean that undiscovered issues in
a new design may go unnoticed if we finalize too soon.

	Scott

On Tue, Oct 21, 2003 at 12:20:47AM -0700, Bradd W. Szonye wrote:
> As promised, here is my suggestion for revising the collection
> procedures. I tried to remain faithful to the original, and I tried to
> avoid even minor changes. No, really! Nevertheless, I'm sure that it
> will look like a big change. Therefore, let me preface my revision with
> some rationales. Feel free to question or reject them -- as you've
> already seen, I'm amenable to leaving things the way they are if you
> have a good reason to do so.