We can also place FooBrandCheck to a private static field, e.g.

class Foo {
  private static #_FooBrandCheck = new WeakSet();
  constructor() {
    Foo.#_FooBrandCheck.add(this);
  }

  get #foo() {}

  test(other) {
    return Foo.#_FooBrandCheck.has(other);
  }
}

so we avoid the edge cases when FooBrandCheck might be injected to an incorrect scope, e.g. when a class is in the param initializer.

// <-- FooBrandCheck will be injected to here
(x = class { #foo; test (other) { return #foo in other } }) => {}

Ohh I love this idea

I wish class access were not stage-2. The class binding can be overwritten. Guess we may have to stick to temporary variable.

Q: Is _FooBrandCheck.has(other) equivalent to other instanceof Foo?

No, it's different when other is a subclass of Foo

If Bar, a subclass of Foo, has super() in its constructor, does it imply #foo in bar is true where bar is an instance of Bar?

Oh I was confusing this test with the private fields one. instanceof is different because it checks the prototype:

class Base {
  constructor() {
    return {};
  }
}

class Foo extends Base {
  #foo;

  static check(obj) {
    return #foo in obj;
  }
}

new Foo() instanceof Foo; // false
Foo.check(new Foo); // true

class Foo {
  #foo;

  static check(obj) {
    return #foo in obj;
  }
}

let foo = new Foo();
foo.__proto__ = {};
foo instanceof Foo; // false
Foo.check(foo); // true

class Foo {
  #foo;

  static check(obj) {
    return #foo in obj;
  }
}

let foo = Object.create(Foo.prototype);
foo instanceof Foo; // true
Foo.check(foo); // false

If Bar, a subclass of Foo, has super() in its constructor, does it imply #foo in bar is true where bar is an instance of Bar?

If by "bar is an instance of Bar" you mean bar instanceof Bar then no, there isn't an implication in any direction.

can we default nativePrivateFields to !isRequire("proposal-private-methods", api.targets())?

This isn't necessarily intended to be a public api right since we can just check targets? Or did we want to be able to specify that

Ideally every plugin should automatically compile as few as possible based on the targets, but users should still be able to override it via options.

Would it be easier to rename the class, instead of all conflicting bindings?

I think I'll leave this as-is: renaming a class is always observable (because it changes the .name), while renaming the other conflicts is often not observable (if we rename a variable). It can still be observable if the conflict is with a class/function, but at least it's not always.

Nit:

This is used for instance methods, but it's a single weakset for all the instance methods in the class.