I'd say this is indeed a redundant cast as self.x doesn't have a type prior to this assignment. If you have x: SomethingIncompatible annotation, cast won't be marked redundant. How problematic is this use case for you, especially given that the fix is as trivial as self.x: Foo = 'a'?

I suspect the logic goes as follows: during the first pass we have an unknown type and infer x: Foo, then during the second pass the assignment looks like self.x: Foo = cast(Foo, "a") which is clearly a redundant cast.

The reason this looked like a regression is that I've only seen this happen with literal types. This doesn't generate an error:

# mypy: warn-redundant-casts

from typing import cast

Foo = int | str

class C:
    def __init__(self) -> None:
        self.x = cast(Foo, "a")  # No error

Is there an inconsistency?

Indeed, that's a bit inconsistent: we only detect unnecessary casting to Literal types in this scenario (same if you annotate x: Foo directly in the body of C). That happens because we do infer literal types when in literal context, but never infer other union types when one of the union members suffices. This discrepancy isn't a new regression, it just happens to surface with --warn-redundant-casts is enabled.

I'd argue that this aspect of new mypy behavior is correct: the cast is redundant. So the actual bug is that we fail to report cast(int | str, 'a')? Given that --warn-redundant-casts is more of cosmetic lint (violation mean that the user might have missed something, not that a program is ill-formed from typing POV), I think detecting some new cases is better than not detecting, even if somewhat inconsistently.

Hm, no, my bad, this still looks weird. It's a positive change, but I don't understand why it actually happens.

Why do we infer a union of literals somewhere when its subset would suffice?