It's still pretty common for typeshed to do things because of mypy or to not even land changes in the first place that affect mypy output

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

Regarding dict.__or__, this is likely due my PR: python/typeshed#14284 where some overloads were removed that purely existed in the first place to address quirks and ancient unresolved bugs in mypy (in particular, #3933 from 2017, #5874 from 2018).

In fact, it seems that then and there the decision was made to instead of fixing this properly, to just add some overloads in typeshed:

Solving both return type context and argument constraints in one go seems to be the only somewhat promising way to solve the issue that I can think of. This would be a big change however, and it could result in other difficulties.

My proposal is to revert the change to the signature of list.__add__ in typeshed.

But the presence of these overloads lead to downstream problems:

• divergence between type checker inference: polymorphic overloads on list.__add__ and dict.__or__ lead to divergences in type checkers. typeshed#14283
• subtyping issues with protocols due to [spec] overload subtyping rules are too strict. typing#2021

The best solution would be to fix #3933 / #5874, then I believe these hacks would no longer be necessary. I spend a whole lot of time/effort last year to make a patch (randolf-scholz#4), but I could never quite satisfy the whole test suite, and it appears that there are more underlying issues with mypy that need to be fixed first, such as bugs in *args handling (#20472 / #19651) and some weird behavior of literals in meets (#19560)