Current behavior is a major bug/discrepancy in the specification. In general, terrible precedents have become a core part of JS language design culture

[celmaun]

While I'm not opposed to this particular proposal because it's useful to have syntactic sugar for this.constructor.staticMethod() (as class.staticMethod()) in instance methods. Isn't the current behavior in static methods a bug? Why is it that:

class Parent { #x = 123; getX() { return this.#x; } }
class Child extends Parent { } 
new Child().getX() // -> 123

but

class Parent { static #x = 123; static getX() { return this.#x; } }
class Child extends Parent { } 
Child.getX() // -> Uncaught TypeError: Cannot read private member #x from an object whose class did not declare it

This TypeError makes no sense to me. Why is there such a major discrepancy in static vs instance methods when subclassing? I could understand retaining problematic functionality in decades old JS syntax for BC and the need for coming up with stuff like strict-mode. But now even for relatively new functionality, it has become a part of culture in JS language design that major new syntax is proposed/added to the language with added complexity and years are spent on debates to retain unintuitive erroneous behavior instead of making a simple fix w/ some urgency. This direction is quite obviously problematic and unhealthy for the future evolution of JS in the long-term.

See also, the assignment-override-mistake, tc39/ecma262#1320 tc39/proposal-stabilize#4

Sorry for using direct language to make the point, I don't mean to offend anyone.

[ljharb]

The difference is in static private fields, specifically, and it was an intentional part of the design to prevent very common subclassing bugs wrt constructors with shared objects, as I recall.