http://dvcs.w3.org/hg/webcomponents/rev/b2709fa45d1b

Re-opening: no one is happy with cloneNode ignoring content and allowing content to be read/write.

More commentary below

My concern about cloneNode(deep) also cloning content was a worry about excessive memory use in the case of recursive templates. My idea was that content wouldn't be cloned, but it was settable, so sharing of content as well as cloning were all possible via script, but the default was most conservative.

Because serialization walks into the content, the problem with allowing content to be settable is that it creates the situation where disallowing hierarchy cycles becomes complicated (a single DocumentFragment can now have multiple template "hosts" and the isDescendant becomes hairy).

After long discussions with Dimitri and Adam, I am convinced that

a) cloneNode(deep) making a "full" copy of the template and its content is a necessary use case and is most consistent with the current expectations of cloneNode

b) logically, an "instantiate" operation is entirely possible both via script and later to be added to the template spec, if necessary. "instantiate" would "share" content, but not directly, it would create a reference to the "source" template. Serialization would only traverse through content, not "ref" and thus cycle prevention would be no worse.

Thus, I plan to return to Dimitri's original spec in this regard, by making content read only and having cloneNode clone contents as well as the node.

http://dvcs.w3.org/hg/webcomponents/rev/96d3865c980d