Inconsistent optional type resolution for AbstractSet and Set

Bug Report

Inconsistent optional type resolution for AbstractSet and Set.

To Reproduce

from typing import AbstractSet, Set


def check(x: int) -> None: ...


def foo(x: int | None, s: AbstractSet[int]) -> None:
    if x in s:
        check(x)  # error: Argument 1 to "check" has incompatible type "int | None"; expected "int"  [arg-type]


def bar(x: int | None, s: Set[int]) -> None:
    if x in s:
        check(x)  # no error

Expected Behavior

The resolved type after x in AbstractSet and Set should be the same.

If it needs to be consistent with other type unions, the additional type resolution should not happen:

(this is how it currently works for int | str, no additional type resolution happens)

from typing import AbstractSet, Set


def check(x: int) -> None: ...

def foo(x: int | str, s: AbstractSet[int]) -> None:
    if x in s:
        check(x)  # error


def bar(x: int | str, s: Set[int]) -> None:
    if x in s:
        check(x)  # error

Actual Behavior

In a branch where x of Optional[T] is in Set[T], x's type is resolved into T, however that does not happen with AbstractSet.

Your Environment

• Mypy version used: 1.8.0
• Mypy command-line flags: with and without --strict
• Mypy configuration options from mypy.ini (and other config files): none
• Python version used: 3.12

Start by running the provided Python reproducer with mypy 1.8.0 and compare the AbstractSet and Set cases in foo and bar. Trace the type narrowing performed for x in each collection and add coverage for the reported behavior. Done means both collection types resolve the optional value consistently with the chosen expected behavior.