I tried opening a thread in the past concerning this topic, together with a GitHub issue in the typing specification repository. Both of them had not much success (with great frustration I must add, but alas it is what it is). Perhaps the OP of this thread will be luckier than me.
My typical use case is to use type[Proto] to express the possibility of making a guard/filter function that can return an instance of an object if it passes the isinstance check against a reference protocol type. It’s all part of a framework leveraging discoverable plugins, but in general that’s the go-to approach that some of the users in the issue pointed by @NeilGirdhar usually refer to.
And concerning Callable, I’m not particularly convinced and I would probably go for a dedicated Constructable type as pointed by @mikeshardmind (hopefully I didn’t misunderstand their intention). Still that objection was refuted multiple times in different conversations (in the past an AbstractType was suggested).
And I think that the issue shouldn’t be left to type checkers for experimentation but formalized in the typing specification through appropriate PEPs. There have been in the past (hopefully my mind is not playing tricks on me) complaints or points raised about the fact that type checkers are divergent in behaviour and ruleset and there was a desire for more convergence. I get that experimentation allows for discovering possible new use case scenarios involving more complex type annotations, but for issues like these that have been going (on the mypy side) for over 6 years, there should be a desire for a formalization. Or at least a more serious discussion about it.
It’s a specification, if it’s not meant as such shouldn’t it be renamed to guideline then? And this is a little bit of a deliberate provocation, so take it with a grain of salt.