Votes on issues on which I have an opinion, and discussion of a couple
of the issues:

    iota defn				Count based
    Naming: iota			(IOTA ...) only
    circular lists			See below.
    improper lists			See below.
    TAKE & DROP				Separate left and right versions.
    Removing PROPER-LIST?		Yes.
    map function termination condition	#1.
    FIND, FIND-TAIL n-ary		No.
    alist functions in separate lib?	Yes.
    Are the right-duplicate deletion procedures worth inclusion?
					Yes.
    lists-as-sets funs put in separate module?
					Yes.
    Naming: REMOVE / DELETE conflicts	Happy with your sol'n.
    Naming: right & left variants	See below.
    destructive/linear-update		See below.
    Naming: ACONS or ALIST-CONS?	ALIST-CONS.
    Argument order of = equivalence predicates
					Spell it out.

Circular and improper lists: I am opposed to even acknowledging the
existence of circular and improper "lists" in the proposal.  I suggest
instead that you break the functionality of the SRFI-1 procedures on
circular and improper lists out as a separate SRFI so that
implementations that want to support that behavior may do so; I find
that I use circular and improper lists only very rarely, and almost
always disguised as non-list-like data structures.

Naming right and left variants: I argue once again for '-left' and
'-right' suffixes, alternately for '' and '-right' suffixes.  Artificial
succinctness in naming isn't worth the bother it brings about.

Destructive/linear-update: Contrary to what you say, your revised
proposal does not serve my concern.  My concern is threefold:

  (1) I want side effects.  This concern is served by your proposal,
      although I dislike the secondary status you give procedures with
      guaranteed side effects.
  (2) You give existing names new meanings, thus breaking working code
      and alienating implementers (including myself :-).  This concern
      is not served by your proposal.
  (3) You give an existing naming convention, the ! suffix, a new
      meaning.  This concern is not served by your proposal.

You're constructing a new class of procedures in the language.  What's
the problem with choosing new names for the new procedures?  What's the
problem with selecting a naming scheme that does not conflict with those
of existing classes of procedures?

--lars