Saxon

The byte code generation for the key() function has apparently not been enhanced to handle the "composite" option in XSLT 3.0.

I've reviewed the byte code for key() and it looks to me as if it isn't doing anything that is likely to give a significant performance benefit compared with a call-back to the standard library implementation. We've eliminated specialised bytecode generation for a number of functions where there was no apparent benefit but it seems this one escaped the axe. Essentially, the cost of generating bytecode (and the memory occupied by the bytecode) can easily exceed the run-time speed-up in such cases. I'm therefore going to resolve this by killing off the specialised bytecode generation for the key() function.