The SameSite errors are not authentication related. The partitioning warnings are IMO fine, there is still value in those cookies as long as Chrome doesn't partition/block them (that's like 80% of the userbase).

There are hundreds of calls to set cookies like:
https://meta.wikimedia.org/wiki/Special:CentralAutoLogin/setCookies?type=1x1&from=plwiki&usesul3=1
https://species.wikimedia.org/wiki/Special:CentralAutoLogin/setCookies?type=1x1&from=plwiki&usesul3=1
https://incubator.wikimedia.org/wiki/Special:CentralAutoLogin/setCookies?type=1x1&from=plwiki&usesul3=1

18 x 5 calls to be exact, it's a five-step redirect for every domain in $wgCentralAuthAutoLoginWikis.

That's edge login, done since 2010 or so. The user impact is that you will be logged in when you visit any other wiki, rather than not being logged in and then getting a popup that you have been logged in in the background and please reload. Once could certainly argue the tradeoff is not worth it (although "it clutters my developer console" is not a very strong argument, specifically).

Filter out sites to which I don't contribute.

When you visit a site you haven't contributed to before, your account is automatically autocreated and you are logged in already on the first pageview. That requires session cookies.

Again, one could argue it shouldn't be done that way, it has been done that way since 2010.

Set cookies on main domain:
https://pl.wikisource.org/ -> .wikisource.org
https://pl.wiktionary.org/ -> .wiktionary.org
https://pl.wikinews.org/ ->.wikinews.org
https://pl.wikibooks.org/ -> .wikibooks.org
https://commons.wikimedia.org/ -> .wikimedia.org
https://www.wikidata.org -> .wikidata.org
That would mean 3-10 cookies, and avoid setting up separate sessions on 150 websites.

This is pretty much what happens. I'm not sure where you got the idea that 150 websites are involved.

It does mean a lot of cookies anyway because there's something like 7 cookies per session.

I visit https://www.wikifunctions.org/wiki/ I see it as if visited: https://www.wikifunctions.org/w/index.php?title=Wikifunctions:Main_Page&useskin=monobook
I'm immediately redirected to auth.wiki.
I'm back to wikifunctions fully authenticated.

This is how a number of other websites deal with SSO. Those are typically websites which can easily differentiate between the URLs that are only useful after authentication, and the ones where authentication doesn't matter. Wikipedia is not like that. Most URLs are content, but what you can do with that content and how it looks depends very much on whether you are authenticated. Which means it's hard to decide whether there should be an SSO redirect. Unwanted redirects are bad, e.g. because they don't preserve the URL fragment.

That would mean 3-10 cookies, and avoid setting up separate sessions on 150 websites.

This is pretty much what happens. I'm not sure where you got the idea that 150 websites are involved.

That's not what happens. I see many calls loading fake 1x1 png image. For example en.wikivoyage:

https://en.wikivoyage.org/wiki/Special:CentralAutoLogin/start?type=1x1&from=plwiki&usesul3=1

And I don't even use en.wikivoyage ;). There were 86 requests even when I just visited pl.wikipedia.org. There are separate calls to en.something and pl.something. I didn't debug this, but this definitely doesn't look like 3-10 websites to me. So no, it doesn’t work the way I described as an expected result.

It also seems SUL3 just lost my session even on my home wiki and just after 3 hours. I had to manually refresh the page which is just annoying. I hope this part at least is some temporary caching/proxy problem or something like that. Because this is actually worse then before SUL3.

In T390830#10703440, @Nux wrote:

That would mean 3-10 cookies, and avoid setting up separate sessions on 150 websites.

This is pretty much what happens. I'm not sure where you got the idea that 150 websites are involved.

That's not what happens. I see many calls loading fake 1x1 png image. For example en.wikivoyage:

https://en.wikivoyage.org/wiki/Special:CentralAutoLogin/start?type=1x1&from=plwiki&usesul3=1

And I don't even use en.wikivoyage ;). There were 86 requests even when I just visited pl.wikipedia.org. There are separate calls to en.something and pl.something. I didn't debug this, but this definitely doesn't look like 3-10 websites to me. So no, it doesn’t work the way I described as an expected result.

There are 18 wikis on the list, which is a lot, but not 150. Each one of them starts a chain of up to 5 requests where each one redirects to the next step, which explains why you're seeing ~86 requests.

For the wikis with multiple language editions, the cookie are set for top-level domains (e.g. wikipedia.org, not en.wikipedia.org), which causes you to be logged in in all languages. Using e.g. enwiki in that list is just an arbitrary choice.

The only way to avoid these warnings would be to remove the "edge login" feature, which would indeed make our system more like a standard SSO auth. Personally I kind of wish that we'd do that (since it's complex, and it will no longer work once all browsers block third-party cookies), but for a very long time, we have promised things like "Special:UserLogin now logs the user in to every unified wiki simultaneously" (quote from https://meta.wikimedia.org/wiki/Help:Unified_login), so such a change may be a surprise to users, and we don't want to make it lightly.

In T390830#10704848, @matmarex wrote:

The only way to avoid these warnings would be to remove the "edge login" feature, which would indeed make our system more like a standard SSO auth. Personally I kind of wish that we'd do that (since it's complex, and it will no longer work once all browsers block third-party cookies), but for a very long time, we have promised things like "Special:UserLogin now logs the user in to every unified wiki simultaneously" (quote from https://meta.wikimedia.org/wiki/Help:Unified_login), so such a change may be a surprise to users, and we don't want to make it lightly.

I filed T391288: Consider removing edge login and subresource autologin in the future for future discussions about this. We are very much not planning to do it now or soon, though.