There isn't consensus. I just haven't chimed in because Eric has said everything I would want to say.
On use cases:
We've used subclassing of Any as a way to type Mock's in typeshed for basically forever. This is mentioned in Python 3.11's What's New, the original typing-sig thread and discussed at PyCon US 2022. I've used this for a very dynamic parametrisation situation, where I had specific objects that I wanted to be able to duck type as anything (while ideally preserving its extra methods). I've also used it as a way to more easily duck type through an incorrectly strictly typed interface that I couldn't change. I remember recommending this to people on
gitter.im / stackoverflow, but I don't remember the specifics of their use cases, possibly something something metaclass.
Paul, I'll also say that when proposing a revert, coming at the question with the assumption that "neither of these can be reasonably answered" is maybe not the best approach. It feels very Cunningham's Law.
On the process to make the original change:
Given that all major type checkers already supported it, typeshed already used it since antiquity, no concerns were raised on the typing-sig thread, it made syntax in pyi usable in py (without hacks), this wasn't a controversial change.
On interpretation:
Eric's already mentioned how it should be interpreted, but since you asked again: type checkers should treat subclassing of Any the same way they would subclassing of an unknown symbol. This typically looks something like the example below, but semantics here haven't been standardised, so a type checker could choose to approach this differently:
```
from unknown import anybaseclass
class X(anybaseclass):
def foo(self) -> int: ...
reveal_type(X().foo()) # reveals int
reveal_type(X().bar()) # reveals Any
class A: ...
def takes_A(a: A): ...
takes_A(X()) # okay
```
On how to revert:
The onus is on you to prove why this should be reverted (the default position is that features do not get reverted). Arguments that I think could lead to a revert are showing why this breaks the type system or is an unreasonable lift for type checkers. I think it will be hard to make those arguments, since this was already part of our gradual type system, and all type checkers already had to have behaviour to handle it.