Regarding the second error case, the "option parameter conventions" (1.5) state clearly what is and isn't considered an error for the $options argument supplied. Rule 6 says:

For each named option, the function specification defines a required type for the option value. The value that is actually supplied in the map is converted to this required type using the function conversion rules. A dynamic error occurs if the supplied value cannot be converted to the required type, or if the value after conversion is not one of the permitted values for the option in question. **The error codes for this error are defined in the specification of each function.**

The WG accepted Debbie's proposal to have new dynamic error conditions for fn:load-xquery-module as described in the bug entry. We also agreed to leave it to the editor to create new appropriate error codes for these conditions.

I'd like to "reopen" this (though it hasn't actually been closed) because I think Debbie's suggestions for extra error conditions actually raise a couple of questions about the spec.

(a) fn:transform defines an option saying what version of XSLT needs to be supported.

Specifically:

xslt-version	xs:decimal	The minimum level of the XSLT language that the processor must support. Defaults to the [xsl:]version attribute at the outermost level of the stylesheet.

I think fn:load-xquery-module should have a similar option? 

Proposal: have an xquery-version option:

xquery-version	xs:decimal	The minimum level of the XQuery language that the processor must support. Defaults to the value appearing in the version declaration of the loaded module, or implementation-defined in the absence of such a declaration.

Then add the error condition:

FOQM0006 is raised if no suitable XQuery processor is available.

(b) For load-xquery-module we say:

Nodes that are passed to or from the dynamically loaded module should retain their node identity. However, if this is impossible to achieve (for example, because nodes need to be reconstructed into the representation used by a different software product) then the tree containing a node may be copied, causing a loss of node identity.

which is not quite the same as what we say for fn:transform:

Where nodes are passed to the transformation, for example as the value of the context item or of a stylesheet parameter, they should if possible retain their node identity, their base URI, and their relationships to all other nodes in the containing tree (including ancestors and siblings). If this is not possible, for example because the only way of passing nodes to the chosen XSLT implementation is by serializing and re-parsing, then a node may be passed in the form of a deep copy, which may lose information about the ancestors and siblings of the node, and its relationships to other nodes passed across the interface.

(also, it's a note in one case and a rule in the other).

I suggest unifying these to avoid any unintended differences:

Where nodes are passed to (X), for example as the value of (Y), they should if possible retain their node identity, their base URI, and their relationships to all other nodes in the containing tree (including ancestors and siblings). If this is not possible, for example because the only way of passing nodes to the chosen (XSLT|XQuery) implementation is by serializing and re-parsing, then a node may be passed in the form of a deep copy, which may lose information about the identity of the node, about its ancestors and sibling, and about its relationships to other nodes passed across the interface.

The changes were accepted and have been applied.