After some time living with it, I really don't like our current default behavior that all # type: ignore are considered blanket # type: ignore, even if they have a code (we currently assume the code is a mypy code and ignore it). This is a behavior that I'd never recommend anyone intentionally use, which makes it unfortunate as a default. It's also directly contrary to the expressed user intent to only suppress some specific type error.

IMO this comment is correct, and the ideal form for multi-checker suppressions is # type: ignore[mypy-code, ty-code, pyrightCode] -- this is much nicer than # type: ignore[mypy-code] # ty: ignore[ty-code] # pyright: ignore[pyrightCode].

The one tweak I would make for ty is that I think we should avoid any possible ambiguity by supporting # type: ignore[ty:invalid-assignment] (note the ty: prefix on the code) rather than # type: ignore[invalid-assignment].

Thus, I propose that we:

1. Start supporting # type: ignore[ty:some-ty-code] as a valid code-specific suppression comment, equivalent to # ty: ignore[some-ty-code].
2. Start supporting # type: ignore[one-code, another-code] (multiple comma-separated codes -- just as we already do for # ty: ignore).
3. Stop treating # type: ignore with a code as blanket. If a # type: ignore has codes we don't recognize, those just don't have any effect in ty; they don't suppress anything. If there's a # type: ignore with only unrecognized codes, it does nothing.

I think our existing respect-type-ignore-comments config setting can continue to function as it does today, although with these changes I'd expect the use cases for setting it to false to be fewer.