Dear Chaw,

thank you very much for your careful reader and the many valid points you make. Let me address them in sequence (the resulting changes will appear in the next draft).

  * Regarding the first issue noted in the SRFI, would it make sense
    to consider an alternate name for maps?  Of course, "map" in the
    key-value sense is well established, but I think the name-clash
    with the higher-order map is quite awkward (e.g., map-map,
    map-map->list, ...).  Perhaps 'dict' or some other such name?
"dict" is often associated with hash tables so while I think that "map" isn't optimal, "dict" is neither. For an alternative, what do you think of "mapping" instead of "map"?

  * The use of 'codomain' in the abstract confuses me.  To me, it
    seems more natural to refer to the domain of keys and (perhaps)
    the codomain of values, given the usual key->value mapping.
Should have been "domain" (we are not going to work in the opposite category). Fixed.

  * I am also confused by the parenthetical remark in the last
    paragraph of the Rationale: "Multi-sets (i.e., relations)...".  I
    can imagine a multi-set as a relation from the domain of its
    elements to nonnegative integers (denoting number of occurrences),
    but I suspect I am missing something more obvious here.  I am
    interpreting multi-sets as bags (cf. SRFI 113).  Now it occurs to
    me perhaps multi-maps are meant here.
Was a typo on my side. "multi-map" was meant. Fixed.
  * In the Linear update section, second item under "benefits to this
    convention": I don't understand how programmers may continue to
    assume maps are functional data structures in the presence of
    potential side-effects of the "!" procedures.  Is the intention
    that this assumption can be made provided no "!" procedures are
    used?
Yes. As long as any map is not an argument of a "!"-procedure, it can be considered to represent a functional data structure. Added a brief clarification.

  * In description of make-map: "set" in second sentence should read
    "map", and perhaps "elements" should read "associations" for
    consistency.
Fixed 
  * For map-set and map-set!, I assume the number of 'arg's has to be
    even but the specification does not seem to require that, strictly
    speaking.
Yes; clarified.
  * Is the motivation for map-delete-all and map-delete-all! avoiding
    having to use 'apply' with a large number of arguments
    (potentially unsupported by an implementation)?
That could be one motivation. My motivation was to make SRFI 146 as much orthogonal to SRFI 113 (which has been accepted for inclusion in R7RS-large) as possible. And SRFI 113 provides equivalent procedures.

  * For map-search, is it an error if the failure and success
    procedures call their continuation arguments in non-tail
    positions, or more generally do something else with the given
    continuations?  I would imagine so, but the phrasing in terms of
    "expected" made me wonder (not sure if unexpected use in this
    context is error).
It is an error if they are not invoked in tail position in the failure and success procedures. Or if the failure and success procedures return to their implicit continuation without invoking the continuation arguments. Fixed.

  * Are the two lists returned by map-entries guaranteed to be ordered
    consistently by the associations (i.e., such that the i'th key
    from the first list maps to the i'th value from the second)?  I
    would guess not, but a clarification either way may be useful.
Yes. Fixed.

  * Would it make sense to add procedures similar to map-keys,
    map-values, and map-entries that return SRFI 113 sets and bags
    instead of lists (for potential efficiency gains by avoiding
    intermediate lists before using list->set etc.)?  Perhaps not;
    just a thought.
I am not whether it is worth because it would create a dependency on SRFI 113 (and one may want to implement SRFI 113 on top of SRFI 146). One can use "map-fold" to easily generate sets or other data structures of keys, and values.
  * Submaps section, first sentence: "sets" should be "maps".
Fixed.

  * Submaps section: Probably implied, but it may be helpful to state
    explicitly that equality of associations is defined as equality of
    their keys and values (especially since in earlier procedures the
    comparisons are limited to keys).
Good idea. Fixed. 
  * For the linear-update procedures, is it correct that they may
    (potentially) side-effect multiple 'map' parameters?  That seems
    to make sense to me, but the explanation in the "Linear update"
    section says "... side-effect *one* of their parameters" (emphasis
    mine).  This question probably only makes sense for the last four
    procedures in "Set theory operations" (which I think are the only
    !-procedures with multiple maps).
At the moment, it is undefined which argument is side-effected upon. (This is exactly how it is in SRFI 113.)

One could add that only the first map argument may be mutated; but this may put unwanted pressure upon implementations. Or that all map arguments may be mutated (but are there algorithms, for which this would be crucial?).

  * Does map-xor (and map-xor!) take exactly two arguments (by analogy
    with SRFI 113 set-xor), or at most two?  In any case, a
    clarification/restriction of the "..." in the signature would be
    helpful.
This was a copy&paste-error. Fixed. 
  * I found the last paragraph of the Comparators section a bit
    confusing.  My understanding is that it specifies that the default
    comparator (in the SRFI-128 sense) for maps is obtained by
    invoking make-map-comparator on the default comparator for the
    value portions of those maps.  But I am not sure.  Some
    clarification/elaboration here may be useful. Also, in light of the earlier comment on maps with keys that are
		maps themselves, it may be worth noting the analogous case (though
		perhaps obvious) for maps with values that are maps (which is
		where the above would be more interesting, I think).
Added a few bits. And removed first paragraph of the section, which may be confusing. However, I don't know how to explain "map-comparator" better. It is stated explicitly, isn't it: map-comparator === (make-map-comparator (make-default-comparator), so, yes, the default comparator of SRFI 128 is used to compare values of maps in the presence of the default comparator. 
  * (minor) In some cases, the explanation of a linear-update version
    of a procedure repeats the explanation for the functional version.
    Given the explanation earlier in the SRFI, I think it may be
    clearer/shorter just to say "foo! linear update version of foo"
    unless there is some unusual detail.
For coherence with SRFI 113, I reused much of the structure and wording. 
  * very minor typos: explicitely, thre
Fixed.
  * Somewhat tangential: Are there plans for (optional) procedures for
    ordered versions of maps (and sets)?  I think the ordered versions
    are often useful (cf. SortedMap, SortedSet in Java).  In
    particular, if the underlying implementation (e.g., red-black
    trees) makes it easy to access elements in order then it seems odd
    to not suggest exposing that functionality in a standard way.
In the latest iteration of my proposal (which will become the next draft together with corrections/clarifications based on your comments), I have already added a means to determine whether the underlying implementation uses hash functions or ordering predicates. In the latter case, I can add that "map-fold", "map-keys", "map-find", ... respect the order.

Best regards,

Marc