The JS equivalent regexp is:

/^((?:(?:#REDIRECT|#redirect)[ \t\n\r\x0c]*(?::[ \t\n\r\x0c]*)?\[\[[^\]]+\]\])?(?:\[\[(?:Category)\:[^\]]*?\]\]|__(?:NOGLOBAL|DISAMBIG|NOCOLLABORATIONHUBTOC|nocollaborationhubtoc|NOTOC|notoc|NOGALLERY|nogallery|FORCETOC|forcetoc|TOC|toc|NOEDITSECTION|noeditsection|NOTITLECONVERT|notitleconvert|NOTC|notc|NOCONTENTCONVERT|nocontentconvert|NOCC|nocc|NEWSECTIONLINK|NONEWSECTIONLINK|HIDDENCAT|EXPECTUNUSEDCATEGORY|INDEX|NOINDEX|STATICREDIRECT)__|<!--(?:[^-]|-(?!->))*-->)*)(<nowiki>\s+<\/nowiki>)([^\n]*(?:\n|$))/im

Note that the PHP version, in addition to adding unnecessary ?P<a_notoc> groupings, is also doubling the leading and trailing underscores, so instead of matching __NOTOC__ the PHP version is looking for ____NOTOC____ etc.
The part of the regexp which matches the HTML comment is also over-escaped in PHP, so it's matching literal parens instead of grouping.

Tagged and pushed 2.1.0 to composer.

T233136: Code debt: should extension API know about frames? is related.

@Catrope: oops, sorry, I had it in my head that {T204371: Replace initial colon in (hash-prefixed) parser function invocation with vertical bar} was already implemented, instead of still future work.

There's also wikimedia/zest-css
Perhaps even wikimedia/assert as well.

This is a workaround for https://bugs.php.net/bug.php?id=77686 and other issues related to inconsistent indexing behavior. See also the implementation of DOMCompat::getElementById in 10dedbbeb626aa614b5931c07035675e01590259 and the implementation of getElementById in Zest, for example in d118dcc45b803917e5e34d60712b893b3892d5ac, and the discussion in T215000#4993172 and T215000#4994273 and the PHP documentation in https://www.php.net/manual/en/domdocument.getelementbyid.php and https://www.php.net/manual/en/domelement.setidattribute.php

(More of the workaround is in T232390: Remex does not use \DOMElement::setIdAttribute('id') by default.)

Might be related to T232390: Remex does not use \DOMElement::setIdAttribute('id') by default.

So this is another case where T215000: Fill gaps in PHP DOM's functionality bites us again and we need T217867: Port domino (or another spec-compliant DOM library) to PHP for a proper fix. But I've got a reasonable workaround.

No, I found it. From DOMDataUtils.php:

	public static function storeInPageBundle( DOMElement $node, Env $env, stdClass $data ): void {
		$uid = $node->getAttribute( 'id' ) ?? '';
		$document = $node->ownerDocument;
		$pb = self::getPageBundle( $document );
		$docDp = $pb->parsoid;
		$origId = $uid ?: null;
		if ( array_key_exists( $uid, $docDp->ids ) ) {
			$uid = null;
			// FIXME: Protect mw ids while tokenizing to avoid false positives.
			$env->log( 'info', 'Wikitext for this page has duplicate ids: ' . $origId );
		}
		if ( !$uid ) {
			do {
				$docDp->counter += 1;
				$uid = 'mw' . PHPUtils::counterToBase64( $docDp->counter );
			} while ( DOMCompat::getElementById( $document, $uid ) );
			self::addNormalizedAttribute( $node, 'id', $uid, $origId );
		}
		$docDp->ids[$uid] = $data->parsoid;
		if ( isset( $data->mw ) ) {
			$pb->mw->ids[$uid] = $data->mw;
		}
	}

Note the loop in the middle, which calls getElementById() for every id it assigns, in order to ensure it's unused.
But DOMComat::getElementsById() calls ZestInst::getElementsById, and here's that code:

	public static function getElementsById( DOMNode $context, string $id ): array {
		$doc = ( $context instanceof \DOMDocument ) ?
			$context : $context->ownerDocument;
		// PHP doesn't provide an DOMElement-scoped version of
		// getElementById, so we can't call this directly on $context --
		// but that's okay because (1) IDs should be unique, and
		// (2) we verify the scope of the returned element below
		// anyway (to work around bugs with deleted-but-not-gc'ed
		// nodes).
		$r = $doc->getElementById( $id );
		// Note that $r could be null here because the
		// DOMDocument hasn't had an "id attribute" set, even if the id
		// exists in the document. See:
		// http://php.net/manual/en/domdocument.getelementbyid.php
		if ( $r !== null ) {
			// Verify that this node is actually rooted in the
			// document (or in the context), since the element
			// isn't removed from the index immediately when it
			// is deleted. (Also PHP's call is not scoped.)
			for ( $parent = $r; $parent; $parent = $parent->parentNode ) {
				if ( $parent === $context ) {
					return [ $r ];
				}
			}
			// It's possible a deleted-but-still-indexed element was
			// shadowing a later-added element, so we can't return
			// null here directly; fallback to a full search.
		}
		// Do an xpath search, which is still a full traversal of the tree
		// (sigh) but 25% faster than traversing it wholly in PHP.
		$xpath = new \DOMXPath( $doc );
		$query = './/*[@id=' . self::xpathQuote( $id ) . ']';
		return iterator_to_array( $xpath->query( $query, $context ) );
	}

The only obvious use of Zest in the pagebundle path I can see is:

		$dpScriptElt = DOMCompat::getElementById( $doc, 'mw-pagebundle' );

from DOMDataUtils::extractPageBundle(), called from ContentUtils::extractDpAndSerialize(), called from Parsoid::wikitext2html(), called from ParsoidHandler::wt2html().

Is there any way to get a fuller stack trace for the failure?

I have a multi-stage plan in my head for conversion, starting with 1) deleting existing html/php clauses where we already have an html/php+tidy clause, 2) if a marker at the top of the file is found, always read html/php as html/php+tidy, 3) one by one in core and extensions add the marker to the top of the file and update the tests to match (which should ensure that the diff is readable and only includes actual differences introduced by tidying the output, not bookkeeping changes), and then 4) require the marker/normalizing the naming of the clauses/remove the no-tidy paths in the test case.

In T230683#5432585 @Anomie proposes using the revision ID of the edit that creates the comment as its persistent identifier.

The fact is that we have a huge amount of preexisting content, and editors trained on our current markup. Regardless of how you might *prefer* comments be formatted, the existing content on our talk pages uses list item syntax, and new comments by our existing editors will use list item syntax as well. I'm not opposed to adding new syntax for comments, but it needs to interoperate really well with existing-and-future list-item talk page markup. That, combined with the long standing bugs&wishes around existing single-line list item syntax, seems a reasonable basis for considering general improvements.

In T230665#5423058, @Anomie wrote:

This is prevented by the runtime type system. What looks like a string is actually a Symbol; you can't add symbols or concatenate them.

You're proposing a language with no string concatenation? That seems nearly unusable for something to be used with wikitext.

In T230683#5425135, @Anomie wrote:

In T230683#5424146, @cscott wrote:

Reasons are in T230658: in particular it provides extensibility for outdent or other special formatting,

As I said there, IMO manual outdenting should just go away. No idea what "other special formatting" someone might want on a comment itself rather than the content of the comment (which then belongs as wikitext in the content of the comment).

For completeness, another proposal is to automatically scan for a trailing signature (perhaps using the {{#~|user|date}} syntax from T230653) and using the timestamp from this as part of the automatically-generated ID. I'm not a huge fan of this proposal because (a) requires non-local effects on list item markup, and (b) seems to be too talk-page specific, but it's certainly worth mentioning for discussion that automatic ID generation based on content doesn't have to quite as simplistic as the ID generation for headings is.

That's a reasonable alternative; I've added it to the list in the task description. There are some weird corner cases w/r/t properly closing the list; I think we want some sort of multiline list syntax anyway (T230683: New syntax for multiline list items / talk page comments), so it might make sense to tie the attribute syntax to that. But there are multiple proposals for multiline lists, too.

My point is that there are a number of levels of indirection between local username and some stable notion of "real user". Over time the local username can map to a different local userid, and in term the local userid can map to a different SUL userid. I don't think we should try to solve the global identity problem.

In T230659#5431727, @Alsee wrote:

Edit to clarify: If this were expected for all or most comments I would consider it a non-starter. If this is some rare special purpose feature, equivalent to how on rare occasion we put an anchor link on a section, then I withdraw that concern.

In T230683#5423080, @Anomie wrote:

Also it needs a companion proposal for T230658 that's not awful. Since > doesn't have a unique "list start" indicator (the same character is used for line continuation) it seems awkward to specify where list item properties would or would not belong.

Why? This isn't a list at all, it's markup for a comment on a talk page. Why would you need class and data and such on a talk page comment (rather than in its contents)?

In T230653#5423059, @Anomie wrote:

In T230653#5422815, @cscott wrote:

We usually leave a redirect page in place for user renames. For example: https://en.wikipedia.org/w/index.php?title=User:Cananian&redirect=no

I'm not sure a redirect would be the best thing to do. What if someone retargets it? What if someone usurps the old name?

If you do new syntax, then you still have to figure out how to add attributes (at least outdent information, and ideally an I'd as well) to that new syntax.

In T230665#5422173, @Anomie wrote:

We usually leave a redirect page in place for user renames. For example: https://en.wikipedia.org/w/index.php?title=User:Cananian&redirect=no

Two open questions for > syntax are: how to actually express a break between list items, since usually

>>> This is an item

Re-opening, to stand for the idea of a cleaner wikitext 2.0 syntax, which keeps coming up from time to time. The desired properties in the task description are still valid.

I've added this as a subtask of T150417. That task seemed to focus specifically on localizing Lua; I'm looking at JavaScript in this task. Because we don't (yet) have a Scribunto API for JavaScript (T61101), we're not quite as constrained by backwards compatibility of existing code.

In T230653#5420529, @Esanders wrote:

It would also be nice if the parser function output contained this structured data, e.g. <span data-timestamp="YYYYMMDDHHMMSS" data-user="Bob">....</span>

The basic idea is to remap:

var foo = "bar";
var obj = {};
obj.bar = 3;
return obj[foo];

to

const $1 = Symbol("bar");

Slides presenting some syntax examples at
https://commons.wikimedia.org/wiki/File:Wikitext_2.0.wikimedia.devsummit.2017.pdf

Very short presentation on this: https://commons.wikimedia.org/wiki/File:Wikimania_2019_-_New_Wikitext_for_Chat_Pages.pdf

ZZ from Google is at Wikimania 2019 and will be on the panel at https://wikimania.wikimedia.org/wiki/2019%3AQuality/Idea_jam_on_quality on Sunday.

(And I agree with @Tgr's response to @Lydia_Pintscher that this issue isn't directly related to MCR. In my mind it is about what "output types" and "input types" are available for templates/extensions during preprocessing. Currently extensions can output a wikitext string or raw HTML, and as parameters they can only have a string (usually interpreted as a wikitext string). This task broadens both the possible output types and the possible input type to include structured data.)

You can use the {{lowercase}} template on your user name, which will ensure that the first letter is displayed lowercase on your user page at least. This uses the {{DISPLAYTITLE}} magic word. See https://web.archive.org/web/20190410170303/https://en.wikipedia.org/wiki/User:cscott .

Duplicate for the -{ change and intended feature for the Special:MyLanguage change.

I suspect Special:MyLanguage was enabled for all projects by T68762: Move "Special:MyLanguage" from Extension:Translate to MediaWiki core in June 2014.

Tech news notifications documented in T165175, which is linked from the page I cited above.

Duplicate of T189095 for the first part. Not a new change.

This was an intentional change to make preprocessor behavior more uniform. Just entity-escape the - or the { if you don't want language converter syntax, or wrap the -{ in a <nowiki>. See T54661: Preprocessor/Parser irregularities with -{...}- variant constructs. and T146304: Preprocessor should handle -{...}- variant constructs in template arguments. We had wikilint volunteers fix these issues with out existing content, they can probably help you out with tools if that's helpful. https://www.mediawiki.org/wiki/Parsoid/Language_conversion/Preprocessor_fixups discusses the wikitext fixup process in more detail.

FWIW, in T196440#5341715 I moot around the idea of a specialized "arglist" data type to be returned by a template, to make certain argument-list manipulations easier/more robust. I think this "structured data" input/output type would work well for that. {{#arglist}} would emit the arguments to the current template in the side channel key-value format, and {{#filter-arglist|....}} would accept that side channel format as input.

I bet we'd want to go with #3, at least initially. I think we'd prefer not to add Parsoid and it's dependencies to mediawiki/vendor's composer.json (#1) because of the HHVM/PHP 7.2 thing. #2 is attractive, and I suspect we might want to do that once we move past testing and start putting Parsoid into production, but I bet we don't want to jump on the deploy train quite yet.

...or we could stop using the DOM extension, I suppose (T217867). I'm not a fan of the quality of that code....

I don't know if it needs direct access to dom diff. But if it recursively invokes the serializer for a subtree, it should be a SelectiveSerializer; ie we should be doing selser and domdiff on that subtree. And we should be smart enough that if a subtree of an extension tag mismatches, we should pop up and reserialize the entire extension tag (using the extension tag's handler), not try to splice it in ourselves.

I think there's some longer-term planning considerations here: