Discussed this during Tech forum today. tl;dr is I'm fine with an attribute for the <pre> extension tag to control this behavior, although I'd prefer that it's not called html because I don't want to encourage the "wikitext is a superset of HTML" confusion. The <pre> extension tag, even with this functionality enabled, still has quite a number of differences with its HTML counterpart. I'm fine with parsewikitext or just parsed or just wikitext or whatever, just leave "html" out of it. :)
A related issue is that as used on-wiki, the <pre> extension ostensibly requires access to the parent frame:
[[Template:Demonstration]]
<pre parsed=true>
This is my argument: {{{1}}}
</pre>As presently implemented, the contents of the <pre> extension (in Parsoid land at least) are "raw text", and if we try to parse this to wikitext we can't properly expand the {{{1}}} because we don't have access to the parent frame.
*However* this distinction between "expanded wikitext" and "raw text" arguments is deeper than this, and we /already have/ a mechanism to pass the body contents of the extension tag "as expanded wiki text" to wit:
[[Template:Demonstration]]
{{#tag:pre|This is my argument: {{{1}}}}|parsed=true}}This works as intended: the {{{1}}} is expanded in the frame of [[Template:Demonstration]] before the argument is passed to the implementation of the <pre> extension tag.
Veering a little bit off track, I'll point to T268144#7704327 and the general extension tag/parser function uniformity issues (T204370 will stand-in for that discussion). Part of the idea is that *any* argument ought to be able to be passed/fetched either "as raw text" or "as expanded wikitext", which roughly corresponds to "lazy" or "eager" evaluation of the arguments in the traditional programming languages sense. We showed above that the "body" argument for an extension tag can be passed in either form, depending on whether the html-ish <tag> or template-ish {{#tag:...}} syntax is used. It would be desirable to be able to do the same for *any* argument to a transclusion, and perhaps this can be part of the semantics of {T114432: [RFC] Heredoc arguments for templates (aka "hygienic" or "long" arguments)}. That is, we already can pass an "expanded wikitext" argument like:
but if we wanted to pass the argument instead "as raw text" you might write it as
{{Foo|arg=<<<
some | raw | text | ignore | markup
>>>|bar}}This is a little bit at odds with one of the motivating examples for heredocs (from T114432):
{{cite|id=“32412”|<<<
First person plural pronouns in Isthmus-Mecayapan Nahuat:
:''nejamēn'' ({{IPA|[nehameːn]}}) "We, but not you" (= me & them)
:''tejamēn'' ({{IPA|[tehameːn]}}) "We along with you" (= me & you & them)
>>>}}In this example we very much wanted the "raw text" interpretation of the = characters, but we *did* want to eventually evaluate the wikitext and expand it.
The basic idea for a solution is that the parameters are passed in as a variant type which the implementation can "demand" as appropriate type from using an asFoo() method. In this case, the Cite extension would take the body argument and call body.asParsedWikitext() on it. When provided with a variant type containing raw text, the asParsedWikitext() method would parse it. When provided with a variant type containing "expanded wikitext" it would also skip the initial preprocessor/expand-templates state (to avoid double expansion) and parse it from there.
Similarly, .asExpandedWikitext() on the argument provides the usual value for compatibility with existing parser function etc implementations, regardless of whether it was passed as raw text or already as expanded wikitext. .asHtml is appropriate if the output is going to be spliced into an HTML output, and works regardless of whether the argument was provided as wikitext, as raw text, or as HTML (from the strip state; see T257606#9216471).