While we're at it, does it make sense to also update the second argument to allow for xs:anyAtomicType?, or xs:string??

It simplifies writing (a variant of):

  string-join(1 to 4, if(@separator) then @separator else '')

into

  string-join(1 to 4, @separator)

assuming the second argument follows from string($arg2), so the empty sequence as in string(()), will return the empty string.

Our general approach has been to distinguish "input" arguments from "control" arguments. Input arguments are likely to originate from the source document being queried, control arguments are likely to originate from the query logic itself. Input arguments generally allow an empty sequence, control arguments do not. I think that the separator is correctly treated as a control argument; a use case such as yours where it derives from the source document is unusual. Therefore I think it the type should remain exactly-one.

Note also, the use case in comment 1 can be done with

string-join(1 to 4, string(@separator))

If you want a concise way of using a different default separator you can write

string-join(1 to 4, (@separator, '#')[1])

(In reply to Michael Kay from comment #2)
> Our general approach has been to distinguish "input" arguments from
> "control" arguments. 

Ok, makes sense. I wasn't aware of that distinction.

I'm aware of the similar ways of writing the if-statement, I think my original idea came primarily from the feeling of "what is sauce for the goose is sauce for the gander"... 

But that can equally well apply to the argument that any control argument should be exactly-one.

The proposal (changing the first argument only) was today accepted.

I happened to notice that this is not in the draft yet.  Apologies if you were already aware of this.

Thanks for the reminder. It had indeed slipped under the radar. Now done.