I am interested in the first bullet point as you correctly quoted from Section 8.4.2 of WS-BPEL 2.0.
"Replace the element at the destination with a copy of the entire element at the source, including [children] and [attribute] properties."
Full stop, no need to proceed further since the remaining bits are about keepSrcElementName.
<ns1:sourceNode xmlns:ns1="namespace1" xmlns:ns:2="namespace2">
<ns3:targetNode xmlns:ns3="namespace3" xmlns:ns4="namespace4">
Should result in:
<ns3:targetNode xmlns:ns1="namespace1" xmlns:ns:2="namespace2" xmlns:ns3="namespace3">
But in ODE it results in:
The problem with the result in ODE is that it is missing the namespace declaration for <ns2:sourceChild>. This will cause problems when trying to parse the xml again. I ran into this exact issue and it took me a while to figure out where it was going wrong since I'm running ServiceMix and wasn't sure if the problem was in there or ODE.
To be fair, my original report above has no context or additional info for which I apologize. I'm pressed for time and banged out a few bugs while trying to get my app to work. I'll spend the extra couple of minutes next time to put together something more coherent, although a patch with unit tests isn't likely coming soon.
If you look at the replaceElement code in ASSIGN, you'll see that it skips over the namespace decls for the source node. It relies on a util method call below to copy the namespace decl from the target node onto the replacementElement. If you look at the history of the file, there was a change made to skip over the namespace declarations back in 2008 although I don't understand why.
My comment about the copying namespace declarations over from the to-spec onto the replacementElement being a violation of the RE strategy were secondary to the real bug which is not copying the source decls over. By copying over all of the namespace decls from the to-spec to the replacementElement you're doing something that isn't specified and in fact may inadvertently be changing the element's meaning. Not having looked at the namespace context propagation code, I'm not sure how it handles namespace collisions or encoded namespaces within text or CDATA but even if it worked perfectly, it seems unnecessary – although again, a subtle issue which is minor in comparison to the original problem.