I can see two ways of handling this:

• Try to ensure the user is logged in by the time of the edit, by doing a top-level redirect either when they open the editor or when they submit the edit. This is strightforward for the old editor, but not really possible for JS-based editors as far as I can see. (Maybe via a popup window?)
• After the edit, when we do a central login redirect, special-case the situation where the user is already logged in centrally and do a user merge.

Or we can just ignore the problem and accept that some fraction of temp users will have multiple identities (a fairly large fraction, given the impending Chrome third-party cookie deprecation).

@Tgr is this something that your team intends to look at?

Had a chat with @kostajh about this and we realized that the impact will be very limited:

• Because the CentralAuth session provider sets a parent-domain cookie when the temp account is autocreated with $login=true, all other wikis in the same family will recognize the temp user immediately.
• The central login that happens after the user's first edit is pretty reliable today (it's a top-level redirect) and that sets cookies for the central session on login.wikimedia.org (with SUL3 it will be a different domain but otherwise the process will be unchanged). These are not set on the parent domain (for security reasons, as wikimedia.org is not a MediaWiki-only domain), but the paradigm browsers generally use for cookie access is same-site, not same-domain, so that means accessing the central cookies during autologin should work in most browsers when the top-level document is a wikimedia.org subdomain. In practice this means that the temp account will reliably transfer to Wikimedia Commons too (which is the most likely candidate for "temp user switches to a different project and edits there too" behavior).

So in practice there aren't many user workflows that are affected - maybe editing a Wikipedia page and then going over to Wikidata to edit something that's used in the infobox?

(This also means there is no way to test this behavior until temp users are rolled out to multiple top-level domains. Or at least not normally - you can manually delete some cookies I suppose.)

The conclusion was that this is probably fine to ignore - we might find that it's more problematic than we imagined and reassess, but there is no need to do anything unless that happens.