Saxon

See new test case si-iterate-039. Reported on saxon-help mailing list by David Rudel. My initial response:

I've reproduced the problem.

I don't know if your source document had nested 'a' elements: mine did, and the logic certainly needs to cater for the possibility. Because a elements can be nested, the code for //a/snapshot needs to be capable of building more than one snapshot concurrently. Technically, these could be delivered in any order, because the document ordering of nodes in different trees is implementation-defined; but because the logic is shared with other functions, I think Saxon delivers the snapshots in a way that respects the document order of the original 'a' elements. This means that the snapshot for an outer 'a' element is buffered, and is only despatched to the output stream AFTER the snapshots of any descendant 'a' elements have been despatched.

I think what is happening here is that the buffering needed to deliver snapshots in the correct order is interfering with the mechanism used to implement xsl:break. The xsl:break instruction delivers a "pseudo-item" to the result of the xsl:iterate, and the control logic detects this pseudo-item and stops further input being processed. I suspect that the pseudo-item is being buffered and therefore not detected.