Re the dictionary API issue,

I don't have enough experience in generic dictionary handling
to judge the practicality of srfi-44 in this regard.

On the dictionary API issue, I understand that what
Scott is opposing to is to include "efficiency" dictionary
APIs to this srfi, but he agrees the practicality of such APIs
and want them to be covered by subsequent concrete srfi, right?
And Bradd's and Bear's concern is that if srfi-44 is released
without consideration of practical implementation issues,
people will start implementing certain common dictionary
operations on top of srfi-44 in inefficient way,
or just give up srfi-44 and doing their own API.

The ideal resolution, seems to me, to have two srfis submitted
together, one for a generic collection srfi and the other for
a dictionary srfi.   The former just mention a dictionary obeys
generic collection attributes, but leaves the concrete API and
implementation to the latter.

Srfi-34 is referred in this discussion as a sort of "abstract"
srfi that left some concrete parts to srfi-35 and srfi-36.
As far as I remember, however, those three srfis are submitted
altogether (I think it was initially one srfi, then splitted
to three).  Doing that made people easy to understand how
abstract description related to concrete implementation.

I'd feel comfortable if two srfis come together.

--shiro