Overload of `bool` and `int` signatures erroneously reported as overlapping

[Dutcho]

Bug Report
MyPy thinks bool and int parameter signatures overlap (apparently as they're assignable), although it doesn't think the same about int and float (which are equally assignable, though not subtype).
To Reproduce

@overload
def test(b: bool, /) -> Literal['bool']: ...    # Mypy error: Overloaded function signatures 1 and 2 overlap with incompatible return types  [overload-overlap]
@overload
def test(n: int, /) -> Literal['int']: ...
@overload
def test(x: float, /) -> Literal['float']: ...  # Mypy accepts
def test(x: float, /) -> Literal['bool', 'int', 'float']:
    match x:
        case bool(): return 'bool'
        case int(): return 'int'
        case float(): return 'float'
        case _: assert_never(x)

Expected Behavior
I expected MyPy to accept this (runtime works).
Actual Behavior
However, MyPy reports:

# error: Overloaded function signatures 1 and 2 overlap with incompatible return types  [overload-overlap]

Changing the 2nd overload into def test(n: int, /) -> Literal['bool', 'int'] removes the superfluous error, but doesn't express the code's intent.
Potential Duplicates
Reported issues #11165 and #20084 look similar, but sufficiently different that I cannot conclude they're the same (root) issue.
Your Environment

• Mypy version used: 1.19.1 from PyPI
• Mypy command-line flags: both with and without --strict
• Mypy configuration options from mypy.ini (and other config files): none
• Python version used: 3.15.0a6, 3.14.3, 3.13.12 on Windows 11

[ilevkivskyi]

This is actually correct because (weirdly enough) in Python bool is an actual subtype of int.

[Dutcho]

Thanks @ilevkivskyi.
I know bool subtypes int.
But I (apparently incorrectly) assumed (yes, I know her offspring ;-) a series of overloads would logically work like an exclusion (i.e. intersection with negative type). That would result in the 2nd overload effectively being test(n: int - bool) (or test(n: int & ~bool) or test(n: Intersection[int, Not[bool]]) or however this will be written) even before this will ultimately be implemented.
But not, alas, I'll need to wait for those.

[ilevkivskyi]

It is not something to wait for, your code is actually unsafe:

def outer_test(x: int) -> None:
    assert test(x) == "int"

outer_test(True)

[Dutcho]

Very true, but the same applies to float and int (not subtype but assignable and part of very long Discourse threads). With the 2nd overload as test(n: int, /) -> Literal['bool', 'int'], below typechecks fine and fails at runtime:

def outer_test2(x: float) -> None:
    assert test(x) == "float"

outer_test2(42)

Just for my understanding, in a hypothetical future, I'd expect to be able to specify:

@overload
def test(b: bool, /) -> Literal['bool']: ...
@overload
def test(n: int - bool, /) -> Literal['int']: ...
@overload
def test(x: float - int, /) -> Literal['float']: ...

and have MyPy fail on both outer_test and outer_test2.

Is that expectation incorrect? (because that's why I said I'd await those)

(BTW: I hoped optype's JustInt and JustFloat would work as the hypothetical int - bool and float - int.
With it, MyPy accepts the overloads (no overlap etc.), but also outer_test and outer_test2. In other words, no warning at type-checking time of the imminent runtime errors)