I think we can make this simpler if we define map:merge in terms of map:of-pairs. I think the equivalent becomes:

let $FOJS0003 := QName("http://www.w3.org/2005/xqt-errors", "FOJS0003")
let $duplicates-handler := {
  "use-first": fn($a, $b) { $a },
  "use-last":  fn($a, $b) { $b },
  "combine":   fn($a, $b) { $a, $b },
  "reject":    fn($a, $b) { fn:error($FOJS0003) },
  "use-any":   fn($a, $b) { fn:random-number-generator()?permute(($a, $b))[1] }
}
return map:of-pairs($maps =!> map:pairs(), 
                                   $duplicates-handler?($options?duplicates otherwise 'use-first'))

I propose that in each case, the position of the entry for the duplicated key in the resulting map should correspond to the position of the first occurrence of that key in the input sequence. That is, "order of first appearance": the effect should be the same as if new entries are always created using a map:put() operation.

I agree: use-last should only affect values, not keys. I checked various projects, and a popular use case for this option is to overwrite values in a default map:

map:merge(
  ($default-map, { 'debug': true(), 'level': 3 }),
  { 'duplicates': use-last' }
)

When it comes to reordering keys, I believe we should rather offer a separate set of functions in a later step (if we want to do so at all).

Another edge case that may need to be refined in the spec is the replacement of different keys that are deemed equal (1 vs 1.0) with map:put:

{ 1: 'integer', 2e0: 'double' }
=> map:put(1.0, 'decimal')

As the stored key is changed by this update, I think we should treat it not as an in-place update, but as a delete-and-insert operation. One advantage of this would be that the resulting order would unveil what has been going on.

I think we can make this simpler if we define map:merge in terms of map:of-pairs. I think the equivalent becomes:
"use-any": fn($a, $b) { fn:random-number-generator()?permute(($a, $b))[1] }

I think that this one should stay implementation-defined (but I have no idea how to express this in pseudo code…).

Since we are contemplating additional options for map:build and map:of-pairs, perhaps we should move the current $combine parameter into an extensible $options parameter?

Since we are contemplating additional options for map:build and map:of-pairs, perhaps we should move the current $combine parameter into an extensible $options parameter?

…true; this has never been a mistake in the past.