Yeah this is a difficult one.
The scope analysis tooling assumes that each scope follows a tree-like structure. In this instance here the static scope is a child of the class scope.

To make this work "properly", we'd have to restructure the class analysis to handle this. It'd be super weird to setup.

It's probably better to just handle this in the rule - check the shadow and ignore it if the method is static.

It looks like the problem is nestFunctionScope is always setting the upper scope to this.currentScope. If you're in a static method, the upper scope should be the class' parent scope, not the class, I think?

Conditional types had the same problem. You had to visit some of the children under one scope, and the "else" child under the original scope. Maybe it would be easier to have the upper score be a parameter instead of something that is pushed and popped.

The class creates its own scope to contain both the generic type parameter decls, and for the class name (also the class heritage is referenced from within this scope).

If you reference the class name from inside of the class, it references a variable defined inside of the class scope, not the variable defined in the parent scope.

If we were to use the parent scope of the class scope, that would break that relationship, as the static method would reference the class variable defined in the parent scope.

The true fix for this would be to nest an "instance" scope within the class scope, and then define the class generics and instance members within that child scope, and then define static members in the class scope itself.

However this would be a large deviation from the core eslint-scope algorithm, and it's hard to say what the ramifications would be. Rules make assumptions based on what eslint-scope does, so we unfortunately have to adhere to it.