=> Yes. It is consistent with the requirements with SRFI 113 (as I read it).

* (minor) Tangential, editorial/procedural issue: Will the comments
about SRFI 113 in the paragraph before the Index cause
complications for SRFI finalization or R7RS inclusion? In any
case, they do seem like good ideas to me.

=> I think it is important that R7RS (large) is as coherent as possible. I also think that feature detection is a good thing for writing portable code (and is missing somehow in SRFI 113). (The only way to portably use it is to always provide an ordering procedure and a hash function.)

If the Scheme community thinks otherwise, they may possibly vote SRFI 146 into R7RS-large with the exception of any additional requirements made with respect to SRFI 113.

* map-update/default and map-update!/default: Should the
semantically equivalent expressions listed for both use
map-ref/default instead of map-ref?

=> Thanks for the hint! Will be fixed in next draft.

* map-map: The argument comparator seems unused/unneeded based on
the description.

=> Fixed in next draft; the comparator argument should be used for the newly created map.

* (minor) In map-every?, formal argument is named 'set' instead of 'map'
(technically OK, but confusing).

=> Fixed.

* (minor) Above description of map-search!: The signature has
map-search instead of map-search!.

=> Fixed.

* map-ref: Should the SRFI guarantee that the success and failure
procedures will be called in tail positions? Would a similar
requirement make sense for some other procedures? (I did not
check.)

=> That's an interesting point. My sample implementation currently fails to tail-call them, but this could be amended. I quickly scanned over the specification, and the two procedures to map-ref are probably the only ones for which it makes sense to demand that they are being tail-called. I have to think about it. The equivalent hash-table-ref from SRFI 125 should also be looked at.

[Personal note: When R7RS-large is feature-complete, we really need a process that allows to polish this feature set before it is released (e.g. adding tail-call requirements to hash-table-ref from SRFI 125 if this makes the feature set more coherent and orthogonal, ...).]

* (minor) map-search: It was not clear to me whether an
implementation is permitted to return a newly allocated map when
the ignore continuation is invoked. (I would guess not.)

=> It probably shouldn't. The current code, however, does. I am going to update the code. and make the requirement explicit.

* (minor) map-update: The semantics when success (and failure) are
omitted seem obvious but could be made more explicit.

=> added a comment

* (minor) In several places, this SRFI uses "comparison procedure"
to mean (I think) what SRFI 128 calls "ordering procedure"
(different from terminology of SRFI 114).

=> Will update to new terminology

* Is an implementation of this SRFI required to register
map-comparator using comparator-register-default! of SRFI 128? If
so, I think it will be beneficial to state it explicitly. If not,
I don't understand how the behavior described just before
"map-comparator" (just before the Implementation section) will
work (other than implicitly modifying a SRFI 128 implementation to
be aware of maps of this SRFI).

=> A Scheme system natively supporting SRFI 128 and SRFI 146 will not have to use comparator-register-default!. If SRFI 146 is implemented independently to SRFI 128 (e.g. my sample implementation), the comparator-register-default!-hook will have to be used.

* (very minor) The link to the sample implementation goes to just
the .sld file instead of the top of the Github respository.

=> Isn't this a good choice?

* The very last test in srfi/146/test.sld of the sample
implementation seems to me like it should fail:

(define map1 (make-map comparator 'a 1 'b 2 'c 3))
...
(define map5 (make-map comparator 'a 1 'c 3))
...
(test-assert "<?: case 3" (<? comparator map1 map5)))))

=> Why? 'b comes before 'c and the maps are sorted in lexicographic order.

Thanks again for your very, very valuable comments!

Marc