We currently allow composite sort keys (sort first by surname, then given name), but we do not allow composite access keys (xsl:key) or grouping keys. Instead we require users to construct such keys by string concatenation, which is clumsy and error prone because the result may not be unique, and it prevents use of non-string types as keys.

The simplest way of defining a composite access key would be a new attribute <xsl:key composite="yes"/>. If the use expression is then multivalued, instead of indexing each item in the use expression as a separate key value, the sequence as a whole would be treated as a single key value, to be compared after atomization using deep-equal().

Alternatively we could adopt a syntax closer to that of xsl:sort, using one element for each component of the key.

Similarly for xsl:for-each-group we could add an attribute composite="yes", or we could allow multiple <xsl:group-by> children. 

The advantage of separate elements is that aspects such as collation can be defined separately for each component. The advantage of a composite="yes" attribute is that the number of components does not need to be known at compile time.