Possible partial workarounds (or quasi/pseudo workarounds) known to me:

@Bhsd Yes, I already did try the new (non-"legacy") version, as suggested before. The bug does not occur in it.

Looking at the previous dump 20251220.

Slight update: currently not being able to reproduce the bug in Arch Linux scenario (the same machine/system, not sure what's the "problem"),
but reproduced successfully in OpenBSD (the same machine/system), Firefox version 146.0.1 in both cases; also reproduced in Debian Trixie, Firefox 140.6.0esr.

These are currently not found (HTTP 404):

https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging1.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging2.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging3.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging4.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging5.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging6.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging7.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging8.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging9.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging10.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging11.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging12.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging13.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging14.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging15.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging16.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging17.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging18.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging19.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging20.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging21.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging22.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging23.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging24.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging25.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging26.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-pages-logging27.xml.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-all-titles.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-all-titles-in-ns0.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-siteinfo2-namespacesv2.json.gz
https://dumps.wikimedia.org/enwiki/20260101/enwiki-20260101-siteinfo-namespaces.json.gz

The second example (Crayon … png) unfortunately seem to may have incorrect colors in the original already?
UPDATE: Changed to different one ("Xterm" … png)

related: T178175: {{#time}} parser function should not accept dates with zero in day or month positions

In T178175#6566633, @Rwendland wrote:

This is the documented behaviour, so is correct. …

In T321989#8365615, @RoyZuo wrote:

…
and the problem is not limited to February. on the 31st day of any month, for all the months without the 31st day, this error will occur.
…

I see style

btw, anchors were not mentioned yet, subject of T407884: Vector 2022's sticky header toolbar overlaps beginning of a content linked with an achor (~duplicate issue)

@A_smart_kitten Right, it seems to be describing essentially the same problem. I did not see that one. I would not be against merging.

.. just a note on linking to CodeMirror 5 (legacy): current enwiki production version is 6.0.0, having the bug (too)

@A_smart_kitten

… if disabling subpages in the Talk: namespace is also wanted, please could I ask that it's proposed specifically in an onwiki discussion?

It seems to behave same way for

• enwiki {{Anchor|…}} template (example, w/safemode)
• raw HTML anchor <span class="anchor" id="…"></span> (corresponding to the template output) (example, w/safemode)
• the same with no class, <span id="…"></span> (example, w/safemode)

In some cases, it seems that during the toolbar appearance, page is scrolled correctly anyway. (And, precisely. Unlike as for section links, where a couple of lines above the section header from the previous section are visible too.)
Not sure what exact conditions are needed, but it happens during the same browsing session with the same link, in minor amount of cases.
Btw, I almost always do open these links in a new tab (Ctrl+click).

This has been bugging me for some time (months or years) already. Took me some amount of testing to realize it's a Vector 2022 skin issue for logged in user only. (Initially I wanted to report scrolled-out beginning of anchor links, generally.)

@Tacsipacsi (, @matmarex ) I think that an issue of post signature dates unrecognized (discussion tools timestamp link not made) is unrelated to some invitation banners (not widely known feature).

The were (≥ 10 years ago) concepts to introduce subpages for Czech Wiktionary entries (e.g. here). Never adopted.

Additional remarks: For me it is debatable if it is bug. But it feels so, if trailing period is not considered a part of URL (despite "." being URI uric unreserved character like "-", "_"), but typographic (closing) quote is included.

(I've improved the title, according to emerging agreement at the already mentioned cswikt talk page.)

Related fact: that config value was already in the initial commit of mediawiki-config from 2012.
(Not sure how to trace older history, yet.)

@A_smart_kitten: Regarding related local talk, there really is no final conclusion, no sysop even reacted yet (and some solutions discussed are far from standard).
But thanks for the config code. Czech and Icelandic are the only Wiktionaries having the mentioned option enabled in the main namespace, if I'm interpreting correctly.
But, according to iswiktionary intitle:/\// search results, it seems to be intentional in this latter case.

And it should be disabled mainly for the main namespace (0) with Wiktionary entries/pages.

The issue description Invitation banner not always desired does not seem to match very well the time zone / signature date format problem discussed, maybe either the title should be improved, or new issue created?

(Right, when i dug into my test token generated at Special:OAuthConsumerRegistration/propose/oauth2, I was surprised it contains an exp value corresponding to today's date in year 3024, instead of value nearer to claimed 30 days from now. It would be good if the value was meaningful.)

.. the problem disappears on the second try, but on cleanup apicache-py3/ cleanup it's there again. (but I could not reproduce it on another tries later on)

So in my case, the problem is {{doi:…}} in the page (probably regardless if the prefix handling exists or not, in my case the syntax was not functional in either cswiki and testwiki).
(I've isolated the problem in https://test.wikipedia.org/wiki/Test_bot_doi_problems (ignore the NBSP typo which the script is designed to fix))

In the log I see queries to doi.org.. ??

2024-01-24 16:12:55       _requests.py,  744 in        _json_loads: DEBUG    Non-JSON response received from server doi:doi for url
https://www.doi.org/w/api.php?action=query&meta=userinfo&uiprop=blockinfo%7Cgroups%7Chasmsg%7Cratelimits%7Crights&formatversion=2&maxlag=5&format=json
The server may be down.
Status code: 404

Same problem with pwb.py replace (some older version, then also 8.5.1, 8.6.0, master):

WARNING: Http response status 404
WARNING: Http response status 404
Exception in thread Put-Thread:
Traceback (most recent call last):
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.8/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "/home/m/src/pywikibot/pywikibot/__init__.py", line 399, in async_manager
    request(*args, **kwargs)
  File "/home/m/src/pywikibot/pywikibot/page/_decorators.py", line 35, in handle
    func(self, *args, **kwargs)
  File "/home/m/src/pywikibot/pywikibot/page/_basepage.py", line 1281, in _save
    done = self.site.editpage(self, summary=summary, minor=minor,
  File "/home/m/src/pywikibot/pywikibot/site/_decorators.py", line 86, in callee
    return fn(self, *args, **kwargs)
  File "/home/m/src/pywikibot/pywikibot/site/_apisite.py", line 2057, in editpage
    token = self.tokens['csrf']
  File "/home/m/src/pywikibot/pywikibot/site/_tokenwallet.py", line 60, in __getitem__
    raise KeyError(
KeyError: "Invalid token 'csrf' for user 'MykhalBot' on wikipedia:cs wiki."

on some cswiki page, but did not have problem on some other page.