P.S. Just to mention: in order do not bother anyone - and myself - anymore with the issue, I wrote a primitive Tampermonkey script (see below).

Oh, a conveniently well hidden feature :-) - but it works (can be copied after from the address bar).
Well, I said "Sorry in advance", so the request should be closed then.

In T320529#8936510, @daniel wrote:

I have just successfully made a couple of edits on Russion wikipedia using Visual Editor

In T320529#8935063, @daniel wrote:

VE has been switched to direct mode on all wikis as of 13:20 UTC. So far, all metrics look good.

Overall the question "how many is too many" (@Quiddity) is more philosophical rather then programmatical. While programmers normally prefer more casual definitions.

In T46787#6078162, @Trizek-WMF wrote:

Has using a system similar to the raw watchlist editing mode been considered?

In T46787#6073227, @kostajh wrote:

Is this going to satisfy the use cases that have been written up here?

Yes, that would match perfectly.

In T46787#6071872, @Quiddity wrote:

@Neolexx Yes, that is correct. Unfortunately, it is currently only possible to uncheck all "Page link" notifications. There is no relationship between the "watchlist" feature, and this notification feature, at all.

I am a bit confused by reading https://www.mediawiki.org/wiki/Help:Notifications/Types#Page_links
Is it possible - or even default behavior that

1. the page I once created is not anymore in my watch list
2. the "Page link" notifications still arriving to me because I am the page creator
3. so the only way to stop it is to uncheck "Page link" notification for my whole watch list?

In T250673#6070890, @Aklapper wrote:

@Neolexx: Could you explain why you do not drop that page from the watch list?

To be honnest I'm not quite sure yet: it is not my demand but a reflection of the tech discussion with some arguments (initially linked). So I'm merely this task (feature request) technicak creator and translator.
But I forwarded your question asking to be concise so I would translate it: https://ru.wikipedia.org/wiki/Википедия:Форум/Технический#que01

In T249565#6034913, @Addshore wrote:

Here is a rough list of things that we will see until the table finishes restoring in the next 12-24 hours

The problem still persists at ru-wiki, MBH had to write a bot so once a day to patrol unpatrolled pages after autopatrollers' edits, Which is sounding just like it looks like (=~ wtf)
To avoid terms mishmash: ru-wiki uses FlaggedRevs as its top layer patrolling mechanics. So any further "patrol", "patrolling" means "actions as it is reflected over FlaggedRevs interfaces". If about native tools, then "old patrol", "old patrolling" (as they named in the web-interface).

In T185664#4225088, @Tgr wrote:

FlaggedRevs has two somewhat unrelated sets of functionality: <...>

To be clear I am not in any relations with the WM development team. I am not even a programmer (by my diploma). So my closing proposal doesn't have any authoritative weight. But honestly the way the problem has been last time described - it was a bit like "we used to use DynamicPageList against of its documented settings for desired results; now it refuses to work against of the documented settings - please fix it".

In T234715#5549402, @ssr wrote:

The problem is in DynamicPageList extension. ( {{yes}} template may be ignored now )

In T234715#5549200, @DannyS712 wrote:

Potentially related: T233561: Pending changes: autoreview randomly fails

In T233561#5544804, @Neolexx wrote:

I got an idea of what may happen.

That idea appeared to be plain wrong.
As a round #2 :-) - illogical and random character of the problem reminds me T224491 Which is marked as fixed but maybe that PHP 7 quirk came back here? So sometimes some edit context gets corrupted by one char (say "review" becomes "reviev" or something)?

Since Sep.23 (this bag open by en-wiki user) it seems that there is not any progress. At ru-wiki Землеройкин summed up some facts: "Кратко суммирую факты" ("Summing up some facts").

The extention page states that its authors are Aaron Schulz and Jörg Baach. It may worth to try to contact them because they may know something that only authors know (some hidden deep debugging mode to launch in case of troubles and the like).

I got an idea of what may happen. If I'm right then all problematic articles have been once "patrollled" by setting their "quality" to 0 like
https://ru.wikipedia.org/w/api.php?format=xmlfm&action=query&list=reviewedpages&rpnamespace=0&rpfilterlevel=0&rplimit=1&rpstart=884521
or
https://ru.wikipedia.org/w/api.php?format=xmlfm&action=query&list=reviewedpages&rpnamespace=0&rpfilterlevel=0&rplimit=1&rpstart=5325503

Fresh to whatever UTC-related time (you figure out) problematic article states: https://ru.wikipedia.org/wiki/Википедия:Форум/Технический#samples01

In T233561#5540891, @Neolexx wrote:

but only reviewer may set it to 2, 3 or 1001.

OK, purely technically wrong, even reviewer cannot set it higher than 2(?) The point is that the underlying engine recognizes only zero accuracy state ("not patrolled") and non-zero accuracy state ("patrolled"). And anything else falls under the current editor rights and so we come.

As so far there are very few of "of course" things in it. Let's us take fact that "patrolling" is just an imaginary thing existing only as a social contract and nothing else.
The only real thing is "reviewing" the whole page (not a given edit) accuracy for its states "not acceptable" (0) and "acceptable" (1). And any "patroller" has right to set it to 0 or 1 - but only reviewer may set it to 2, 3 or 1001. So now what may happen if reviewer "patrolled" a page as accuracy==2 and some other "patroller" made an edit after that? Technically it is a request to change the "accuracy" criterion level beyond the allowance (0 or 1) - so the refusal. Just keep brainstorming, don't get too upset.

In T233561#5540276, @MBH wrote:

Don't listen him and his false statements, for example about "engine allows to have articles which are not patrolled but having patrolled last edit" (this statement is clearly wrong).

In T233561#5537361, @Tgr wrote:

In general autoreviews are hard to verify since you have to reconstruct the review state at the time of the edit. Eg. an edit might not get autoreviewed because the parent revision was not reviewed, and then the parent revision might get reviewed later...

Long time ago just for fun I wrote a patrolling script that works straight through the wrapping interfaces: https://ru.wikipedia.org/wiki/User:Neolexx/review.js

In T233561#5537079, @Zache wrote:

In enwiki it is named as "Pending changes" and in flagged revision configuration name is "protection setup" which means that only small subset of the pages are in FlaggedRevs review loop.

To the best of my knowledge en-wiki doesn't use FlaggedRevs extension (as a replacement for the native patrol mechanics). Compare

(update) It seems that currently there is a way to check partial blocks by a 3rd party - through list=blocks query where boolean partial will be set then. For the test case (obviously it's JSON for practical things, I'm using xmlfm just for visual convenience here): https://ru.wikipedia.org/w/api.php?action=query&format=xmlfm&list=blocks&bkusers=Schekinov%20Alexey%20Victorovich

In T232021#5466316, @dbarratt wrote:

Oh there is a way to do this on ApiQueryUserInfo but not with ApiQueryUsers.

I want to understand the use case better - are you using this query for an external tool?

To really laugh one may enjoy my "Type 25 pollution cleaner" I'm keep using these days
https://ru.wikipedia.org/wiki/Участник:Neolexx/common.js

"Don't Shoot the Pianist"... I'm not too deep in IETF and WHATWG stuff so just quoting verbatim from the Chromium response (at the bottom after the line).
So as I understand - they have a word on it from specs guys, URI like urlencoded_part#non-ASCII_as-is_part are simply wrong. They will restore the fix in the next update. But the specs do not prevent any browser producer in the future simply reject such URI as malformed and possibly malicious. If my understanding is correct then such risk should be definitely accounted by the Wikimedia team.

Yeah, they do get saved: just nobody knows about it unless MediaWiki savvy users of Wikipedia. And it just happens in the project that the max article edits and newcomers falls at week-ends.

gerrit is still dead https://www.isitdownrightnow.com/gerrit.wikimedia.org.html

Other related bug

continue from https://phabricator.wikimedia.org/T218393

I'm honnestly puzzled why does it take so long to fix.

To further explain "anything more reasonnable" as I see it, three options:

Why exactly Last News (Последние новости), not Most Popular News (Самые популярные новости) or any other template block of the desktop version?

In T118625#1806070, @Anomie wrote:

so we detect it and throw the error instead.

indeed purged through
thank you!

sorry, posted before saw you response, gonna check now

Thinking over again, I do not understand how any ipblocks table (if it is), even somewhere/completely corrupted, might prevent to get a simple list of users? One cannot give some piece of info - just say "I cannot get it" by an empty string in the relevant query field, do not abort the whole query.