Resolving this task, as Myst has cleaned out the code entirely, and is planning to rewrite it. (per their comment at https://www.mediawiki.org/wiki/Topic:Ulf76ehiw0i5m0g7 and the current placeholder note at https://tools.wmflabs.org/coord/ - I didn't check any further than that.)

Notes: I have now left fresh reminders on the Wikipedia user talkpages of the maintainers for the 2 tools "mentioned" above. Plus I've left a note about the old reply I received in July at T172403. There's nothing else I can do, so as the current assignee on this task I'm lowering the priority - if anyone wants to take over urging those maintainers to update their tools, or has better ideas on how to help them do so, please chime in!

Note: I sent an email in July per T196418#4409358 and I will now leave a user talkpage note.

Note: Braveheart did respond to me in July when I emailed them all, and said that AleXXw had had a look at this, but lacked the time to do the switch to OSM himself. They were going to discuss what to do next, and if there were any alternative solutions.

Note: I did send DB111 an email in July via https://de.wikipedia.org/wiki/Benutzer:DB111 per T196418#4409358 - I will now leave a talkpage comment on their userpage.

Boldly closing. I've marked it as Obsolete in
https://wikitech.wikimedia.org/wiki/News/Cloud_VPS_2018_Purge#OBSOLETE_bots
per
https://wikitech.wikimedia.org/w/index.php?title=Nova_Resource:Bots/Documentation&diff=1784968&oldid=77988

@Addshore, re: this specific task, I think it is still unresolved, and should probably be retitled instead.

This has been effectively overtaken by the upcoming WCG/TCG pages.

(Duplicate of T203206: Wikitech-static not getting all content changes? Not many additional details there though.
But possibly there are clues in the older task from 2017 which has many comments T177450: Not all content is getting replicated to wikitech-static)

Is it the number of Rules that is the problem, or more the number of Conditions? I.e. would it help if we asked users who have 2 rules that could easily be merged, to do so? E.g. H274 and H275 could easily be merged into a single Rule, but it would have the same number of Conditions so merging might not help...

Draft/ongoing work at https://meta.wikimedia.org/wiki/Tech/Ambassadors/Role

Will do. Thank you :)
(I've removed and filtered the spammer)

@hoo ping just in case. It's also unmarked in https://wikitech.wikimedia.org/wiki/Cloud_VPS_2018_Purge

Oh—sorry. Definitely not a power user, at least as far as the underlying coding goes.

[...] though I am familiar with hacking URLs—I can't find the URL in question to hack.

That's precisely what I meant. :-) The URL https://en.wikipedia.org/wiki/Special:Notifications does not currently contain any additional info, beyond the name of the page. It never changes.
Most other special pages have URLs that change when [various things happen, e.g. going to page 2 of the results, or changing a filter]. That's what T137862: Make Notification page filters bookmarkable is asking for (to make those bits of information, each paramater=value pair, be visible and change directly in the URL for each page load)

Good previous explanations also found at:

• https://phabricator.wikimedia.org/T196545#4420688
• https://phabricator.wikimedia.org/T186519#3948023

Personally, I think power-users know how to 'hack' a URL, so a frontend UI change is probably not even needed (but would of course be an optional bonus). Just surface the parameter=value in the URL (as T137862 is also asking for), and editors can hack it when they need to.

Possibly relevant, from Oct 2017: T177450: Not all content is getting replicated to wikitech-static

Notes:
Functionality: The gadget on Enwiki ("Display a floating alert for new talk page messages" (.js/.css)) provides the desired link.
E.g. For 2 test messages at my talkpage, it provides a "view changes" diff link that shows both of them.
It displays the link (and a plain link to the top of the talkpage) in a floating-top-center overlay.

1. add a "(view changes)" link to the end of the existing New message indicator. -- This would make it a bit longer in English, but still not too bad. The French default is a good example of a longer string, as is the French for "View changes". [demo below]
2. add a "(diff)" link to the end [...]. -- This would potentially confuse newcomers. It's short in English, but quite a bit longer in some other languages.
3. add either of those options below the existing New message indicator. -- Kinda messy?
4. other??

In T58845#4541161, @Nemo_bis wrote:

In T58845#4538197, @IKhitron wrote:

It was because clicking on this area calls "open user's talk page un read view" instead of "open user's talk page diff between last watched revision and the current one". It is just not helpful - you can't recognize all the changes.

Yes. sadly, however, keeping this preference would not bring back the direct link to the diffs. If you use a gadget to bring back the link, you can also get the gadget to hide any redundant indicator.

In T202877#4537030, @Kelson wrote:

@Quiddity No, I use my Wikimedia/Wikipedia password. Whatever I use, I do not want that. How to deactivate the 2-factor authentication?

@Kelson it is asking for your 2-Factor Authentication token. You probably used Authy or Google Authenticator or similar?

Hi @Dzahn, We already have and are using a new replacement team-list at commrel-support@wikimedia.org (not mailman).
We primarily just want an email-address redirect, so that anything that is sent to the old cep@lists.wikimedia.org instead comes to our new list. That's it!

The other aspect to keep in mind, is that PROD templates are only ever going to be on an article for very short periods of time. I.e. Unlike most amboxes, such as {{cleanup}}, which can linger for years, there are usually not any pages which have a PROD template for more than 7 days. Subcategories of https://en.wikipedia.org/wiki/Category:Proposed_deletion shows that there is no backlog. So inconsistent formatting might be an acceptable compromise.
There will be similar complexities with the Speedy deletion templates all of which require immediate/urgent author interaction if they object, so it would be good to consider those challenges here, too.

I'm worried that it will become harder to determine which changes we've already seen (e.g. yesterday, or 3 days ago), if we can't tell which day an edit was made.
E.g. If someone's RC is set to a limit of 100 edits and 3 days (so that they can see changes made during a weekend when checking they check on a Monday) then during the week they'll have to cope with the lines they've already seen from n-2 days ago.

Re: task goal - I don't think <blockquote> is specifically needed. The intent of that styling is just trying to make the content of the |concerns=foo unmissable by anyone who has banner-blindness to the generic text in most amboxes. Any alternative suggestions which achieve that result (making "foo" unmissable), via changes to the default template syntax, should be fine.

This seems to be fixed, although (minor issue) it displays a broken-image graphic in the preview

(The description was linking to https://en.wikipedia.org/wiki/Template:Proposed_deletion_notify but was showing a screenshot for https://en.wikipedia.org/wiki/Template:Proposed_deletion - I've fixed that now. :)