Trying to reuse an extended ref before it is defined currently triggers a chain of 2 or more error messages. First "name … defined multiple times with different content", then "no text was provided for refs named …" as a subsequent error, and possible more that get triggered from all that. Minimal code that demonstrates the issue:

<ref name=p20 />
<ref extends=book name=p20>p. 20</ref>

<references>
<ref name=book>All information about the book</ref>
</references>

The problem disappears when …

• When we move the re-used <ref name=p20 /> down below the original ref, everything works.
• When we change the re-use on top to <ref extends=book name=p20 /> with a technically redundant extends= attribute, it also works.

Expected behavior:

• Re-use needs to be possible no matter what the order is. The same is possible with normal ref w/o extends.
• Re-using an extended ref should be possible just with the name, without repeating the extends= attribute.
• Old and new parser need to behave the same (long-term goal, possibly not part of this ticket).

Dev notes:

• The root cause is effectively the rollback stack not supporting rollbacks across multiple dimensions. I.e. it's not only the content that is missing, but the parser has no idea that the ref is going to be an extended one, with very different footnote numbering. See T242141 where we already dug into this edge case. A rollback would need to roll back the already rendered footnote number as well (which was already send to the ParserOutput at this point) – or we need to change the entire approach to assign these numbers only once at the very end.
• In T242141 we decided to (possibly temporarily) block this use-case with an error message, but intentionally re-used an existing error message. The least we need to do is to add a new, much more helpful error message.
• Test cases are already in place. Search for "T240424" in the code.
• This also affects VE, which can be split into a separate task. If a subref reuse occurs first, several bits of logic go wrong because they depend on firstNode having the correct attributes. As an extreme corner case, a reuse of a subref defined before the subref will look like a top-level ref when checking for orphans, and will then fail to detect the orphaning when a subref illegally extends the non-defined subref.