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 in quotation marks 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 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 computed node constructors, the node name must now be written in quotation marksas 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 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.