>And the same code is called when using an index loop (which works as expected) >so far as I can tell it's a "side effect" of using "in".
Let me take some of that back, I was describing a different issue. I think this might be related to parenting issues within XMLList. It can produce very unexpected behavior. In this case, its adding a node to the original parent. Since items added to an XMLList are passed "by reference," its state, including its parent node/place in an existing XML structure, are persisted. Hence, for example, when you create an XMLList out of the elements() of an existing XML object, they will still have a parent value pointing to that original XML object. However, XMLLists also automatically parent new nodes that aren't parented. If you are *adding* a new node to an XMLList, here is the behavior: * If you add an XML node to an empty XMLList, it will not be (re)parented. * If you add an XML node that already has a parent to an XMLList, its parent property will be unaffected. * If you add an unparented XML node to an XMLList... o If added at index 0, it will take the parent of the subsequent XML node (ie: current index 0, which will become index 1). o If added at index > 0, it will take the parent of the previous XML node (ie: index - 1). This entails a few things. Most noticeably, if your first node in an XMLList is unparented and you add an unparented node at index 0, it will remain unparented (because it takes the parent of the subsequent node, which is null). The automatic parenting also occurs when *replacing* an existing node in an XMLList with a different one. Here is the behavior: * If you replace a node (original node) in an XMLList with another node (replacement node), the replacement node will also replace the original node in its parent XML structure as well. * If you replace a node (original node) in an XMLList with another node (replacement node), the replacement node's parent() function will return the value that was returned from the original node. * If you replace a node (original node) in an XMLList with another node (replacement node), the replacement node will still be a child of its previous parent. The significant part of this is that, although an XML node can only have one parent() reference, it may exist in n children sets. Ie: The exact same XML node might be in numerous XML hierarchies, but will only reference the last parent assigned to it. Now take all of that into account. When you add the new node to the XMLListCollection, it looks up the node's parent to determine where it should be added.... and hence we get here. Mike