Apologies in advance if this has been covered in discussions I haven't found.

The current @babel/plugin-proposal-class-properties plugin supports both private static fields and private instance fields. It doesn't allow using the same private name string for both:

class Example {
    static #x = 1;
    #x = 2; // SyntaxError ("Duplicate private field")

    method() {
        console.log(`Example.#x = ${Example.#x}`);
        console.log(`this.#x = ${this.#x}`);
    }
}
new Example().method();

Is that an artifact of the plugin, or is it how this proposal is defined? I couldn't tell from the current spec text.

If it's an aspect of the proposal, this is a mis-match with public fields, where there's no name conflict, and with private members of other similar languages (Java, C#) where having a private static member and a private instance member with the same name is allowed. (I'm not going to say doing it is a good idea...)

It seems like it can be avoided if there's a will/desire to do so, but possibly with a runtime cost. Here's one way (using terminology and structures described in the class fields proposal's spec text):

1. Have "instance" and "static" parts in [[PrivateNameEnvironment]].
2. Allow a name to be duplicated across them (e.g., #x in one doesn't conflict with #x in the other).
3. In AllPrivateNamesValid, check both parts.
4. Have an internal slot on objects saying which part relates to them. The slot on a class constructor says it uses the static part, the slot on all other objects says it uses the instance part.
5. When resolving the name string to a private name object (for instance, in GetValue's step 5.b.ii, quoted below), use the slot to determine which part of the [[PrivateNameEnvironment]] to use.

For clarity, GetValue step 5.b.ii in the class fields spec is currently:

Let field be ? ResolveBinding(GetReferencedName(V), env)

...where env is the relevant PrivateNameEnvironment.

Alternately, a naming convention could be used rather than two "parts" of a [[PrivateNameEnvironment]]. This might be both simpler (since having two "parts" of a [[PrivateNameEnvironment]] makes it no longer a LexicalEnvironment object, making more work) and perhaps more general-purpose for use in the future. With a naming convention:

1. In [[PrivateNameEnvironment]], prefix the binding name of a static private member with the string "static". E.g., static#x vs. #x.
2. (unnecessary)
3. In AllPrivateNamesValid, for the name #x, check both for the instance name (#x) and the static name (static#x).
4. Have a slot on objects saying whether it uses "static" prefixed names (perhaps the slot could contain a generic prefix, defaulting to "", for future expansion). The slot on a class constructor says it uses "static", the slot on all other objects says it doesn't.
5. When resolving the name string to a private name object (for instance, in GetValue's step 5.b.ii), use the object's slot to determine whether to use the name as given (#x) or with a prefix (static#x).

WIth that sort of mechanism, the code block at the beginning of this post would be valid, and would output

Example.#x = 1
this.#x = 2

I don't know the internals of how engines are implementing private members, but I suspect they're able to optimize away the "Let field be ? ResolveBinding(GetReferencedName(V), env)" part of GetValue, which is why I mention a possible runtime cost. If I'm right in my assumption, they wouldn't be able to with this new mechanism (or at least, they could only narrow it down to two possibilities).

I'm not necessarily advocating ensuring that static #x; and #x could both exist in a class, but I thought it worth raising, and ideally when raising a possible issue I prefer to outline a possible solution if I can.

Again, though, the proposal's team may well already have covered this off.