I think it's fine (and so does @Legoktm sitting next to me).

 			// If the user doesn't have 'editmywatchlist', we still want to
			// allow them to add but not remove items via edits and such.

Hmm, no changelog? I'll fix.

Hmm, WatchlistManager->addWatch() and friends all seem to correctly call $performer->isAllowed( 'editmywatchlist' ); is that wrongly returning true for temp users?

In T370771#10015743, @Dreamy_Jazz wrote:

With this change merged, the problem slightly changes. A second request to submit Client Hints data is sent which fails with a 400 error

In T370771#10015282, @Dreamy_Jazz wrote:

In T370771#10015238, @Jdforrester-WMF wrote:

1. Ensure that VisualEditor sets the new value of wgCurRevisionId before calling postEdit.

I don't think VE (or any extension) should ever be writing to those core-set variables.

https://gerrit.wikimedia.org/g/mediawiki/core/+/8e38638501619c11cc27c1f75359b9514e7b2fde/resources/src/mediawiki.action/mediawiki.action.view.postEdit.js#9:

* Code that fires the postEdit hook should first set `wgRevisionId` and `wgCurRevisionId`
* to the revision associated with the edit that triggered the postEdit hook, then fire
* the postEdit hook.

An example of where DiscussionTools sets this value: https://gerrit.wikimedia.org/g/mediawiki/extensions/DiscussionTools/+/5446854a6da7c2c233ddc1636339acba49d5325d/modules/controller.js#713

In T370771#10015055, @Dreamy_Jazz wrote:

VisualEditor fires the postEdit hook without updating the value of wgCurRevisionId. There are a few fixes that I see:

1. Update VisualEditor to not fire the postEdit hook when creating a temporary account (as core seems to do this for us when the page is refreshed)

No response in a few days, assuming yes.

OOUI is owned by DST.

In T364872#9998611, @mpopov wrote:

There are…a lot of "pageviews" coming from just 2 IP addresses that day.

Special:GlobalUsage on Wikifunctions is particularly utilized:

[…]

In T369945#9992410, @Catrope wrote:

I'm happy for https://gitlab.wikimedia.org/repos/releng/release/-/merge_requests/86 to be merged.

A quick note as discussed with Denny that our custom Types for this will need to have special handling – in the orchestrator (special dereferencing, including the new L1234-S1 format), in the front-end (custom selector and renderers), and perhaps elsewhere – and so should be pre-defined Objects rather than created on-wiki.