Such a long primer diff. It seems like I enabled redundant-expr by accident or something like that. I will check it tomorrow.

Regarding pypa/bandersnatch and home-assistant/core, the diff looks good. Regarding pyodide/pyodide, I neither understand why this error is emitted now nor why it is emitted in general (confusing error message). Maybe you know this behaviour already. I could investigate later.

I can reproduce the pyodide problem with Mypy 1.14.1 if I repeat the isinstance check by writing it twice (instead of writing it in a loop), so it is not caused by the change proposed by this PR:

class A: ...
class B: ...

a: A
if isinstance(a, B):
    c = a
if isinstance(a, B):
    c = a  # E: Incompatible types in assignment (expression has type "__main__.<subclass of "A" and "B">1", variable has type "__main__.<subclass of "A" and "B">")  [assignment]

It's sort-of caused by the change here: at the final iteration (when partials don't change) you accept the body once again. This breaks any such inference propagated outside from isinstance (used to infer type of something external to the loop).

I don't believe this is a big deal though (various issues arise with building dicts/lists/... in a non-trivial loop, it's often necessary to annotate the collection anyway).

I do not entirely understand what you are trying to say. However, the same problem can already occur with earlier Mypy versions (that do not check for the number of partials like the master branch Mypy does now) when writing a loop like this:

class A: ...
class B: ...

a: A
cs = []
x: int | str
x = 1
for i in range(2):
    if isinstance(a, B):
        cs.append(a)  # E: Incompatible types in assignment (expression has type "__main__.<subclass of "A" and "B">1", variable has type "__main__.<subclass of "A" and "B">")  [assignment]
    x = "x"

Here, update_from_options causes that the loop body is accepted twice.

So, in my opinion, this issue does not need to bother us in this PR. However, as related false positives would likely be reported more often (in case this PR gets accepted) and as I am curious about the underlying cause, I could try to fix it in a separate PR.

I couldn't track when we started distinguishing ad-hoc intersections, it looks like it is there since long time ago. Anyway, IMO instead of using gen_unique_name() we can simply pull an existing TypeInfo if it is in the current symbol table. Maybe I am missing something, but IIUC these fake TypeInfos should behave as close to the "real" intersections as possible.

@ilevkivskyi: Thank you for investigating. If you can also see no good reason for this behaviour, I will remove this kind of intersection distinguishing in another PR to see if our test suite and the Mypy primer do not complain.

Diff from mypy_primer, showing the effect of this PR on open source code:

bandersnatch (https://github.com/pypa/bandersnatch)
+ src/bandersnatch_storage_plugins/s3.py:62: error: Unused "type: ignore" comment  [unused-ignore]

core (https://github.com/home-assistant/core)
+ homeassistant/components/recorder/migration.py:2280: error: Unused "type: ignore" comment  [unused-ignore]
+ homeassistant/components/recorder/migration.py:2302: error: Unused "type: ignore" comment  [unused-ignore]
+ homeassistant/components/schedule/__init__.py:76: error: Unused "type: ignore" comment  [unused-ignore]
+ homeassistant/components/twentemilieu/calendar.py:73: error: Unused "type: ignore" comment  [unused-ignore]

schemathesis (https://github.com/schemathesis/schemathesis)
-   File "/tmp/mypy_primer/old_mypy/venv/bin/mypy", line 8, in <module>
+   File "/tmp/mypy_primer/new_mypy/venv/bin/mypy", line 8, in <module>
-   File "/tmp/mypy_primer/old_mypy/venv/lib/python3.12/site-packages/mypy/__main__.py", line 15, in console_entry
+   File "/tmp/mypy_primer/new_mypy/venv/lib/python3.12/site-packages/mypy/__main__.py", line 15, in console_entry
-   File "/tmp/mypy_primer/old_mypy/venv/lib/python3.12/site-packages/mypy/main.py", line 119, in main
+   File "/tmp/mypy_primer/new_mypy/venv/lib/python3.12/site-packages/mypy/main.py", line 119, in main
-   File "/tmp/mypy_primer/old_mypy/venv/lib/python3.12/site-packages/mypy/main.py", line 203, in run_build
+   File "/tmp/mypy_primer/new_mypy/venv/lib/python3.12/site-packages/mypy/main.py", line 203, in run_build
-   File "/tmp/mypy_primer/old_mypy/venv/lib/python3.12/site-packages/mypy/build.py", line 191, in build
+   File "/tmp/mypy_primer/new_mypy/venv/lib/python3.12/site-packages/mypy/build.py", line 191, in build
-   File "/tmp/mypy_primer/old_mypy/venv/lib/python3.12/site-packages/mypy/build.py", line 267, in _build
+   File "/tmp/mypy_primer/new_mypy/venv/lib/python3.12/site-packages/mypy/build.py", line 267, in _build
-   File "/tmp/mypy_primer/old_mypy/venv/lib/python3.12/site-packages/mypy/build.py", line 2947, in dispatch
+   File "/tmp/mypy_primer/new_mypy/venv/lib/python3.12/site-packages/mypy/build.py", line 2947, in dispatch
-   File "/tmp/mypy_primer/old_mypy/venv/lib/python3.12/site-packages/mypy/build.py", line 976, in write_deps_cache
+   File "/tmp/mypy_primer/new_mypy/venv/lib/python3.12/site-packages/mypy/build.py", line 976, in write_deps_cache

pyodide (https://github.com/pyodide/pyodide)
+ src/py/pyodide/_state.py:21: error: Incompatible types in assignment (expression has type "pyodide._state.<subclass of "ModuleType" and "JsProxy">2", target has type "pyodide._state.<subclass of "ModuleType" and "JsProxy">")  [assignment]

Seems like the refactoring did not break anything, so this should be ready for merging.

Hmm, unrelated to this PR, but schemathesis stacktrace is interesting AssertionError: Module must be either parsed or cached. Seems like it comes from 3999ab88 in schemathesis (note mypy_primer uses --cache-dir=/dev/null). Opened #18454

Thank you for this PR!

If you can also see no good reason for this behaviour, I will remove this kind of intersection distinguishing in another PR to see if our test suite and the Mypy primer do not complain.

Yes, please go ahead.

🎉 Thank you for the fix!