I read this SRFI with interest.  It will be nice to have a stable
interface to the Map ADT, if for no other reason than to help avoiding
the temptation to overuse/misuse alists.

Here are some rough comments (mostly minor/clarifications) on the
SRFI-146 draft (first) of 2016-12-18.

  * (meta) Since many parts of this SRFI mirror parts of SRFI 113,
    some of the following issues may reflect a larger confusion on my
    part.  Nevertheless, I think clarifications in this SRFI may help.

  * 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?

  * 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.

  * 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.

  * 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?

  * In description of make-map: "set" in second sentence should read
    "map", and perhaps "elements" should read "associations" for
    consistency.

  * 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.

  * 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)?

  * 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).

  * 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.

  * 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.

  * Submaps section, first sentence: "sets" should be "maps".

  * 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).

  * 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).

  * 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.

  * 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).

  * (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.

  * very minor typos: explicitely, thre

  * 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.

Regards,

-chaw