The problem in the test added in PR 21473 is that there is an intermediate base type "object" in the hierarchy:

    class A(type):
        def __setattr__(cls, key, value):
            type.__setattr__(cls, key, value)

    class B:
        pass

    class C(B, A):
        pass

>>> [c for c in C.__mro__]
[<class '__main__.C'>, <class '__main__.B'>, <class '__main__.A'>, <class 'type'>, <class 'object'>]

>>> [c.__setattr__ for c in C.__mro__]
[<function A.__setattr__ at 0x7f3ca4308378>, <slot wrapper '__setattr__' of 'object' objects>, <function A.__setattr__ at 0x7f3ca4308378>, <slot wrapper '__setattr__' of 'type' objects>, <slot wrapper '__setattr__' of 'object' objects>]

I think the change to the algorithm there is too broad, it disables much of what the check was written for (or against).

Given Guido's second (negative) test case, I think it would also not be correct to add "object.__setattr__" to the list of allowed (intermediate) slot methods:

    class A(type):
        def __setattr__(cls, key, value):
            object.__setattr__(cls, key, value)   # this should fail!

    class B:
        pass

    class C(B, A):
        pass

It's difficult to turn this into an algorithm. Is the MRO really the place to look? For "A", we're only really interested in the C-level bases, aren't we?