Maybe these issues have been raised, though I don't find them
in a quick skimming of archive.

* string= conflicts with srfi-13's.  These two can be dispatched by
  examining types of the arguments, and it's nice if it is noted.

* string-contains? is confusingly similar name to srfi-13's string-contains
  which performs different function, so it may be worth noted.

* srfi-1 and srfi-13 consistently use "remove" for the procedures that
  take a predicate, and "delete" for the ones that take an actual element.
  I don't oppose to the different usage in srfi-44, but I think it's nice
  that the difference is mentioned.

* absence thunk in *-ref and *-get : it seems that there are two flocks
  in various Scheme implementations to specify the value of the "fallback"
  values; some takes a value to be returned when no match is found (e.g.
  Chicken, Gauche, STk), and some takes a thunk to be evaluated to
  produce a value to be returned (e.g. PLT).
  I think it is good to stick to one, even though it conflicts with
  existing code; thus I'd like the rationale of API is mentioned.

* "Size versus length" : the definition of srfi-44's size is clear enough,
  but the description of "length" is somewhat confusing; as it says
  "This differs from the concept of length in Scheme datastructures,
  which corresponds more or less directly to the amount of actual storage",
  which isn't really the case (e.g. a string may be represented in
  multibyte format or a tree of chunks, and in such case, string-length is
  a logical notion of number of elements in a string rather than something
  related to the amount of actual storage; indeed, Gauche uses string-size
  to obtain the actual amount of storage used by the string, which differs
  from the number of characters).   So I think it's better not to associate
  "length" and "storage" at all, but just to emphasize "size" is a well
  defined concept and not related to the storage.
  Something like the following, maybe?

     Some Scheme datastructures has the concept of length,
     which may or may not the same as the concept of size.  Particularly,
     the size of a collection is not directly correspond to the amount
     of physical storage it uses.   A collection may occupy more physical
     storage than required to contain its values or mappings.

--shiro