This seems like a pathological edge case and can't personally understand what the desire is there.

Definitely an edge case, but it is one that should be queued for Cite addressing as we have numbers of situations of mediawiki tags inside <ref> that are hosed. Plus that is the point of phabricator.

You may not understand why it needs to be done that way, but is that pertinent? If you are going to present a better solution then do so, otherwise maybe hold judgmental commentary where you don't understand.

For the portrayed case the author of the original work had footnotes across multiple pages along with a split title of the work. It is the neatest (or least ugly) way to code it, so that it transcludes properly and it retains the character of the printed page when not transcluded.

In T141971#2518690, @Billinghurst wrote:

Definitely an edge case, but it is one that should be queued for Cite addressing as we have numbers of situations of mediawiki tags inside <ref> that are hosed. Plus that is the point of phabricator.

I was commenting on my perceived priority, for whenever someone comes along to triage.

You may not understand why it needs to be done that way, but is that pertinent? If you are going to present a better solution then do so, otherwise maybe hold judgmental commentary where you don't understand.

I don't see this as worth responding to.

For the portrayed case the author of the original work had footnotes across multiple pages along with a split title of the work. It is the neatest (or least ugly) way to code it, so that it transcludes properly and it retains the character of the printed page when not transcluded.

Less ugly would be to use a template with the text-to-be-transcluded. Still less ugly would be to repeat the text as necessary. Regardless, if you think this is a common use case, there is yet another solution: design a template to wrap the tag:ref cases, as with Template:Efn on en.wp. And these are besides the case which you have illuminated always works. There are workarounds aplenty, so yet another reason to lower the priority for the triaging person.

Trying to do tricks with templates to circumvent an underlying problem, especially one of problems in a similar series, is not a solution, just a complicating factor. Putting in replication of slabs of text is ugly, and adds to the difficulty in proofreading. It also increases the opportunity for errors especially when you can only check for errors once you have transcluded among multiple pages as wikisource requires in its presentation.

In your schema, I would need to have something like
<noinclude><ref name=$1>$2</ref></noinclude><includeonly><ref name=$1>$3</ref></includeonly>
as we are talking about continuing references, we usually have long text passages so that can be a lot of text with slight differences. In the example that I gave you were then requiring that on two different pages in two different way with wikilinks. That is not good transcription practice.

If we can fix the scenario so that we can have working <tags> inside a <ref>erence tag, that becomes a simple solution.

To add an extra item of difficulty, if a reference has a table within it, it is decidedly better to use <ref> tags otherwise there is the ugliness of trying to use {{!}} in multiple places (even for simple tables this is butt ugly). So the ability to use {{#tag:}} is obviated.

Example of extra gumph that needs to be added
https://en.wikisource.org/w/index.php?title=Page:Considerations_on_the_state_of_Ireland.pdf/6&diff=6676916&oldid=6676821

and it doesn't work!

https://en.wikisource.org/wiki/Considerations_on_the_state_of_Ireland#cite_ref-2

To note that in the end I have managed the issue by use of html syntax of the body of the table and having to <noinclude> table open and close.

This was the way to get around the cite interplay with the second reference [1] to join (follow=) to the first

[1] https://en.wikisource.org/w/index.php?title=Page:Considerations_on_the_state_of_Ireland.pdf/7

Would this also be related to the issue that means {[nop}}'s have to be inserted to get multi paragraph formatted references?

In T141971#3093486, @ShakespeareFan00 wrote:

Would this also be related to the issue that means {[nop}}'s have to be inserted to get multi paragraph formatted references?

Probably not, more likely related to the similar issue with <blockquote> where with two paragraphs the closing </blockquote> tag needs to be on a new line to maintain separation, otherwise it runs them together. With ref issues, I don't use a tag just use a standard <p> or <br />.

This is still broken - https://en.wikisource.org/wiki/The_City_of_the_Saints/Chapter_9 Reference 7.

Probably more an issue with transclusion than with Cite.

This seems like "working as designed" to me. The whole point of the angle-brackets-extension-tag syntax in wikitext is that *everything inside is ignored* until you get to the end tag. That allows you to encapsulate arbitrary content inside an extension tag, which is pretty fundamental. The {{#tag}} syntax is explicitly intended to be the opposite: to allow exposing the contents to the wikitext parser (so that <noinclude> etc work). So I'd lean strongly toward "won't fix" here.

Granted things look a bit weird for extension tags which "seem" to include wikitext. They are implemented via a recursive parse, and so it can be confusing when that recursive parse varies in subtle ways from how the content would be parsed as part of the top-level parse. Perhaps we could argue for more intelligent handling of certain features in recursive parses -- but since there's a semantically-correct workaround with {{#tag}} for this case, I don't think this particular use case is very high priority; plus I believe with the current code structure it would have to be addressed individually for every extension which does recursive parses (which is a lot).

To properly address this, you'd probably want:
a) a new API specifically for "recursive parse within an existing parse context". Perhaps you could use wfDeprecate and friends to ensure was always used for a recursive parse, but complicated somewhat by the use of recursive parses for interface and UX messages which should be independent parses, not recursive parses.
b) Tweak the flags given to the recursive parse using the above API to respect the "top level" flag so that <includeonly> etc are handled the same inside the recursive parse as they would be in the parent context. AIUI this works correctly if the parent context is "top level", but if the parent context is "in a template expansion" the recursive parse is currently popping back to "top level".

"top level" ==> <noinclude> expanded, <includeonly> ignored
"in a template expansion" => <noinclude> ignored, <includeonly> expanded.