Steps to replicate the issue:

• Create the following wikitext:

Text.<ref name="Test" details="Page 1.">Content</ref> More Text.

== References ==
<references />

• Save the page and open it in VisualEditor.
• Copy and paste the 1.1 footnote somewhere on the page.

What happens?:

• Previewing the wikitext everything looks as intended (although currently not due to T403379 but I discovered this bug before the other one existed).

Text.<ref name="Test" details="Page 1.">Content</ref> More Text.<ref name="Test" details="Page 1.">

== References ==
<references />

• While still editing the page in VE the copied sub-reference is shown as an identical re-use.

• Editing the copied / re-used sub-reference changes both identical sub-references.

• Once the page is saved, the copied sub-reference no longer appears as an identical re-use, editing the page again in VE also no longer shows a re-use.

What should have happened instead?:

• Show the copied sub-reference as a separate sub-ref in the reference list (for now, we intend to change this at least in the reader's view).
• Editing the copied sub-ref shouldn't affect the original one.
• The issue doesn't appear when using the re-use dialog instead of copy+paste.

Findings

• The node is shown as a reuse because it shares the same listKey and listIndex, so at the end also the same content and internalItem
• When copy pasting from the same document VE calls VE's ve.ce.ClipboardHandler.prototype.onCopy
• This eventually leads to code that clones the nodes from the document to insert them again
• So copying calls toDomElements but pasting never calls toDataElement on the node
• Instead the ClipboardHandler ends up calling ve.dm.MWReferenceNode.static.cloneElement
• The latter clones the listKey and listIndex so that the sub-ref will create a reuse

Implementation ideas

• When cloning the node, copy the content as well, create a new internalItem and link a new listKey and listIndex
  • Seems not so easy cloneElement cant access the converter or internalList 😢
• I guess we could force the ClipboardHandler to not recognize the nodes on paste by messing with the hash
• We'll not try to improve the C&P handling here, instead we're fixing the visuals and make sure the content can be edit separately

T404415: Make sure that sub-refs with the same listKey (copy and pasted) can be edited and saved with different content
T404414: Make sure that sub-refs with the same listKey get different footnote/reflist numbers
T404412: Make sure that sub-refs with the same listKey are not merged in the reference list view.