I've split out all the fixes you requested that aren't part of this PR, but are instead part of #1668, into a separate commit. Please only review the last commit here :-)

Sorry, I wasn't paying enough attention (re #1668).

as #x has to be declared at the class level, hence always known, in which circumstance #x in this would fail, if I might ask?

#x in this will never throw, but it can return false if you do something like

class A {
  #x = 0;
  hasX() {
    return #x in this;
  }
}
A.prototype.hasX.call({}); // false

@bakkot thanks, but isn't that a violation of the meaning of "private"?

No? It's only the class which is able to do this check; you can't write #x in this outside of A.

@WebReflection this isn't the only object that can hold a private field; imagine static compare(a, b) { return #x in a && #x in b && a.#x === b.#x; }

OK, the class “owns” the private field access, but I wonder what a Proxy trap would do there, and if this check could lead to “leaking” exploits. If Proxy can’t intercept these check then fine, but I didn’t read anything about proxies in the text. If I missed that, no issue, if I didn’t, are private fields leaking via Proxy traps?

@WebReflection Proxy has no ability to detect or intercept private fields, or internal slots.

If there's further discussion to be had, can we have it in the discourse or on the proposal repo, instead of here on the spec PR?

Thanks! Please ignore my comments then, I had a mix of a-aha and “the heck?” moment there. All good 👍