I started digging into this but wasn't able to fully crack it.

• VisualEditor and the citation dialog do have access to the references from within transcluded templates. They appear in the expected place: https://phabricator.wikimedia.org/diffusion/ECIT/browse/master/modules/ve-cite/ve.ui.MWReferenceSearchWidget.js$118
• But they get skipped because they are marked as "placeholder": https://phabricator.wikimedia.org/diffusion/ECIT/browse/master/modules/ve-cite/ve.ui.MWReferenceSearchWidget.js$143
• When I remove this line of code I learn what it means to be a "placeholder": It appears like there is no way to access the content of this reference, and not even the name. They have weird auto-incremented names like "auto/11" that appear to be unrelated to the expected numbering.
• Note that VisualEditor apparently doesn't have access to the actual number of the reference as it will appear in the final rendering. It manually counts: https://phabricator.wikimedia.org/diffusion/ECIT/browse/master/modules/ve-cite/ve.ui.MWReferenceSearchWidget.js$147. This explains why the counting is off in some situations – because the code Parsoid and/or the core parser use to count references is not 100% re-implemented.
• I tried to see if there is a way to access the "child document" of the template transclusion. Something is there, but it's what we have seen when we worked on the template editor: It's a JSON serialization of the raw, unexpanded template, not an actual document where we could find the references.

This explains a series of issues:

• Why references from a template can't be reused via the citation dialog.
• Why the numbering is sometimes weird.
• Why the rendering of the reference list at the end of the article is sometimes different between read and edit mode.
• Why some references say "This reference is defined in a template or other generated block, and for now can only be edited in source mode."
• Why it's possible to accidentally create conflicting names without any warning in VisualEditor, e.g. name=":0" when name=":0" already appears in a template.

At the moment my gut feeling is: It doesn't make much sense for us to dig into this. We would need weeks if not months to learn what's needed to make the necessary, probably fundamental changes to VE's internals. This is probably better done by the Editing-team.

Not much to add here. I came to similar conclusions. ( I was not even able to see placeholder for my transcluded templates in the data ).

Change 917903 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[mediawiki/extensions/Cite@master] Fix empty previews in reference reuse dialog

https://gerrit.wikimedia.org/r/917903

All of the findings make sense to me. I just wanted to add that the Parsoid output seems to include all of the information we might need, so the necessary adjustments would be to Visual Editor so that it parses all of the available data. For example, in https://en.wikipedia.beta.wmflabs.org/api/rest_v1/page/html/User:Adamw%2Fsandbox%2FCite/585110 there is a ref tag produced by a template, and as you see its name {{{name}}} and body {{{body}}} are present in the HTML.

Another finding: VE is able to recognize the ref inside of a transclusion if we add mw:Transclusion to the list of ve.dm.MWReferenceNode.static.allowedRdfaTypes, and also disable ve.dm.MWTransclusionNode self-registration. There's a conflict between the two and it seems that the transclusion node type wins because it gets registered earlier than types defined by extensions. The MWTransclusionNode class even includes a hack to define a trivial matchFunction specifically to force a higher precedence for this type over other node types coming from extensions, so the whole thing feels very deeply baked-in. Defining a trivial ve.dm.MWReferenceNode.static.matchFunction as a counter-hack raises the precedence so that the ref is recognized, but this breaks the name parsing and causes template content to not appear.

My earlier comment was too optimistic about the "name" attribute appearing in output. It's present as part of the DOM element ID, but doesn't appear in structured "data-mw". At my current level of understanding, it's looking extremely challenging to get ref metadata from transclusion output.

Now that I see the shortcomings of the incoming Parsoid document, I'm realizing that the required change is actually to have Parsoid preserve some of the RDFa structures inside of template transclusions, then having VE recognize the elements but preventing direct editing of them. I've asked the parser team about this in Slack.

This exact discussion appears in T214241: data-mw info is clobbered by template annotations. The issue is slightly different than I understood: the ref wikitext parameters are only destroyed if the template emits a ref at the top level. If the ref is nested in a <div> in the template, for example, then the ref data is present: https://en.wikipedia.beta.wmflabs.org/api/rest_v1/page/html/User:Adamw%2Fsandbox%2FRefB

There are still support gaps in this case, and the named ref isn't currently visible to VE but we can assume feasibility since the data is available.

The case of a ref appearing at the template's top level currently has no solution, although a proof of concept patch exists: https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/607632/ .

Tagging @MSantos, we think this set of related use cases (VE support for named refs produced by templates) might make it worthwhile to look at T214241 again.