After quickly skimming that issue thread I think the Pyright devs have a very compelling argument not to add a plug-in system. It would encourage none standard behaviour, when really the type system should be capable of describing all behaviour. I think it may be another plus for it.
I appreciate that argument but some codebases are heavily reliant on “magic” libraries like SQLAlchemy. The SQLAlchemy mypy plugin helps a lot. Well, at least with SQLAlchemy 1.4; dunno if 2.0 needs the plugin
that said, the codebase primarily targets mypy for internal type checking; we tried targeting both tools simultaneously but there were great differences between both tools, which tended towards doubling our workload in getting everything to pass typing fully. In more than one case there were areas where the two tools would mutually disagree with each other, making "correct" typing impossible. This was some iterations back and mypy has had a lot of good releases since then (pyright has had many more, obviously).
when typing a large codebase, there are invariably lots of areas where you just need to "type: ignore" or otherwise do some non-ideal workarounds. it's in that area that trying to target more than one type checker at once gets to be really difficult.
I ran into this issue recently. 2.0 will not need the plugin and work with any Python type checker! So much so that the plugin is already somewhat deprecated.
Seems like dubious logic to me. For example the Django ORM is quite big. Just saying that the type system should handle it and giving up on Django is not a pragmatic choice.