Comparisons between numeric values of different types (for example xs:double and xs:decimal) may give a different result, because the values will now be compared as decimals rather than as doubles. For example, the comparison 3.1 = 3.1e0 will now return false, because the exact value of the xs:double written as 3.1e0 is actually 3.100000000000000088817841970012523233890533447265625. This change is made to ensure that comparison operations are fully transitive, which is a prerequisite for certain sorting and grouping algorithms.
In fn:format-integer, certain formatting pictures using a circumflex as a grouping separator might be interpreted differently in 4.0: for example format-integer(1234, "9^999") would output "1^234" in 3.1, but will output "1621" (1234 in base 9) with 4.0. As a workaround, this can be rewritten as format-integer(1234, "0^000").
In computed node constructors, the node name must now be written as a QName literal (with a preceding # character) if it matches certain language keywords. For example element div {} must now be written element #div {}. (Alternatively, element { "div" } {} and element Q{}div {} are permitted by both XQuery 3.1 and XQuery 4.0.) This change is made because {} is now a valid expression representing an empty map, so expressions such as element otherwise {} could (without this rule) be parsed in two different ways.
In a pragma, whitespace is now required after the opening (# and before the subsequent EQName. This change is made to ensure that an expression such as error(#err:XPTY0004) can be parsed as a function call taking a QName literal as its argument.
In XQuery 4.0, certain expressions are classified as implausible: an example is @code/text(), which will always return an empty sequence. A processor may report a static error when such expressions are encountered; however, processors are required to provide a mode of operation in which such expressions are accepted, thus retaining backwards compatibility.
In expressions that deliver a function item, notably partial function applications, named function references, and the fn:function-lookup function, errors may now be detected at the point where the function item is created when they were previously detected at the point where the function item was called. This was underspecified in previous versions. For example, the partial function application contains(?, 42) is now required to raise a type error (because the second argument should be a string, not an integer) at the point where the partial function application occurs, not at the point where the resulting function is called.
As explained in 3.4.3 Function Coercion, the fact that coercion rules are now applied to global variables and local variable bindings introduces an incompatibility in the case of variables whose value is a function item. Previously it was possible to supply a function item that accepted a wider range of argument values than those declared in the variable's type declaration; this is no longer the case.
Use of an unprefixed function name in a function declaration has a different meaning from XQuery 3.1. In 3.1 and previous versions, this declared a function in the default function namespace (which would cause an error unless the default function namespace was explicitly set to something other than the fn namespace). In XQuery 4.0, the function name will be in no namespace. The distinction will rarely be noticed, because an unprefixed function name in a call of such a function will still work in the same way. It could make a difference, however, if a function call uses a prefixed name in which the prefix is explicitly bound to the default function namespace.