Consider

document { [1] }

The content expression of a document node constructor is processed in exactly the same way as an enclosed expression in the content of a direct element constructor, as described in Step 1e of 3.9.1.3 Content. 

In XQ31 3.9.1.3 Content, point 1.e.i. we read:

"Each array returned by the enclosed expression is flattened by calling the function array:flatten() before the steps that follow."

So this is equivalent to 

document { 1 }

which can be serialized.

Now compare with 

[1]

In SER31, 2 Sequence Normalization, we read:

"Where the process of converting the input sequence to a normalized sequence indicates that a value MUST be cast to xs:string, that operation is defined in Section 19.1.1 Casting to xs:string and xs:untypedAtomic FO31 of [XQuery and XPath Functions and Operators 3.1]. Where a step in the sequence normalization process indicates that a node should be copied, the copy is performed in the same way as an XSLT xsl:copy-of instruction that has a validation attribute whose value is preserve and has a select attribute whose effective value is the node, as described in Section 11.9.2 Deep Copy XT30 of [XSL Transformations (XSLT) Version 3.0], or equivalently in the same way as an XQuery content expression as described in Step 1e of Section 3.9.1.3 Content XQ31 of [XQuery 3.1: An XML Query Language], where the construction mode is preserve."

This refers to Step 1e, but this is only invoked when copying nodes, not function items.

So it would appear that

[1]

cannot be serialized, because the array flattening doesn't occur.

If I'm correct, I think this marks the first time that serialization of

document { E }

and

E

behave differently under serialization (other than in error code).

Was this intentional?