I have several comments on the final draft:

- NULL-LIST? is allowed to handle circular lists in the first sentence of
its
description and disallowed in the third. Taking into account the intended
use of circular lists in MAP-like functionals,  I think that it is logical
to allow
NULL-LIST?  to return #f on circular lists (?)

- It seems to me that UNCONS is a better name for CAR+CDR; it does not imply
addition and this naming convention can be extended to reverse versions of
other
constructors (UNLIST, UNVECTOR etc.)

- TAKE, TAKE-RIGHT: I am still not convinced that "the last 2 elements
of (1 2 3 . d) " are (2 3 . d) and that in this case the benefits of
extended
arguments domain overweight error checking. Scheme's LIST-TAIL
does not handle dotted lists (inspite of the fact that its sample
implementation
won't notice the difference) and I believe there's no *immediate* need to
allow dotted list handling in TAKE/DROP. This is also true for
LIST-COPY and LAST (I can agree that (last-pair '(1 2 . 3)) is (2 . 3)
but the fact that (last '(1 2 . 3)) is 2 still looks like an oddity).

- Searching: the criteria of acceptability of arguments to a search
procedure
based on the result of the search itself (circular lists) is very confusing
and
contradicts the traditional notion of "argument types": acceptability of
an argument should be judged using universal rules ("types" or "domains")
and should not depend on values or types of other arguments. This
approach simplifies  documentation and  understanding of the
procedure's behavior; it also serves as a basis for formal type systems,
both "soft" and static.

As a general note, the list library design process demonstrated weakness
of the Scheme lists concept. It is not a "stable" feature that resists all
attempts
to revise it; some of the revisions are even useful in some situations, and
all the messy details can be carefully documented (see the CL spec).
But original description of lists as finite and NULL-terminated sequences of
pairs, even in its present "unstable" form, is the simplest design choice
that covers all common uses.

I don't think that it is possible to change Scheme's approach to what
constitutes a "list" without  either compromising dynamic type checking
or complicating static type checking. Fortunately (at least that's my
feeling),
improper lists and circular list are not essential and not commonly used
(I consider circular arguments to MAP as kludges that should have zero
effect on language design). My radical proposal is to remove all
references to dotted and circular lists from the library specification
and leave the possibility to extend the spec via the "it is an error"
statements.

I know that the chances to convince Olin so lately in the design process
are close to nothing, but given the amount of work that went into this SRFI
it's still worth a try...

Regards,
Sergei