Danny,

The way the current copy/to functionality reads is as a content replacement not a node copy. Although it is not clear the treatment of attributes and child nodes for query (since there are no examples), but based on the requirement that the types be compatible it would appear to be a complete content copy (attributes and child nodes).

This is a little different then the insertBefore behavior you have described in that you would also be copying the main node. We may want to specify a QName for the child to create if we want the same behavior.

The introduction of a child QName could also solve another issue I am thinking about with your proposed syntax. That question is how one would build up complex content. So if one wants to build a PO/Header/ShippingAddress and you are starting with a blank part what would be the correct syntax. It looks like I can do a raw data move from a literal to the part as a blank template, which I don't particularly like the idea of, or I am out of luck if I don't have a source element QName matching my target. So giving a child QName to create would at least allow you to build up the complex type by a series of blank inserts or appends. If we don't want the series of blank appends the child QName could be replaced with a Path, but we would have to have some caveats on what is allowable for that type of path. In any case I think this requires more thought. My XPath function approach had a little of this described you may want to take a look at it.