Account for discrepancy between soft privacy of `private` vs hard privacy of `#`

With the upcoming TC39 class fields proposal landing in 2022, there is a soft private vs hard private discrepancy between vanilla JS' # and TypeScript's private. This discrepancy might not be obvious to all users and could cause issues.

Maybe the TS docs should highlight this discrepancy, or maybe we should have some kind of warning. Alternatively (and this would have to be raised elsewhere), maybe there should be a TypeScript ESLint warning for this.

TypeScript's private is soft private and has escape hatches like the ability to use bracket notation to access a private field.

The new # private field prefix is hard private and doesn't allow for this. In the example below, TS compiles private and # differently, and the console log at the bottom shows that accessing these values produces different results.

class Dog {
  #barkAmount = 0;
  personality = "happy";

  constructor() {}
}

class Cat {
    private meowAmount = 0;
    personality = "angry";

    constructor() {}
}

const fido = new Dog();
const garfield = new Cat();

console.log(
    fido.#barkAmount, // no good
    fido['#barkAmount'], // no good
    garfield.meowAmount, // no good
    garfield['meowAmount'] // fine
);

Compiles to:

"use strict";
class Dog {
    constructor() {
        this.#barkAmount = 0;
        this.personality = "happy";
    }
    #barkAmount;
}
class Cat {
    constructor() {
        this.meowAmount = 0;
        this.personality = "angry";
    }
}
const fido = new Dog();
const garfield = new Cat();
console.log(fido.#barkAmount, fido['#barkAmount'], garfield.meowAmount, garfield['meowAmount']);

Start by reviewing the TypeScript example contrasting private with # and the linked TypeScript ESLint project. First resolve whether the intended outcome is documentation, a compiler warning, or an ESLint warning; done requires an agreed scope and corresponding documentation or diagnostic behavior.