This sounds like a must-do!

As a user who wants a maximally strict linting config, I'd be super interested to know which rules that I'm using that are inherited from strict and strict-type-checked that are not maximally strictly configured. To start with, can we just document the specific rules that have dumbed-down options? That would allow strict users to fix the problem themselves in the interim until the proposed full multi-option solution exists.

document the specific rules that have dumbed-down options?

Hmm, very interesting. I like the root ask of knowing which rules have opt-in "more strict" options...

I'm of two minds - I like the idea but I also dislike it because it does make things quite a bit more complicated to define and strictly type. The options type we use is not for the config inputs - it's for the "after defaults" merging - which is one reason we haven't added strict types for user configs with our options types.

The last thing I'd want is for us to define a stricter config, roll it out, then find we misconfigured it and it's broken!

Here's a list of rules I'd propose:

• ban-ts-comment: minimumDescriptionLength could be raised from 3
• no-floating-promises: ignoreVoid could switch from true to false
• restrict-plus-operands: turning off many of the allow* options
• restrict-template-expressions: turning off many of the allow* options
• feat(eslint-plugin): [thenable-in-promise-aggregators] disallow non-Thenables to promise aggregators #8094 (comment)
• Edit: oh, and Enhancement: [prefer-string-starts-ends-with] Option to ignore [0] === cases? #7140

it does make things quite a bit more complicated to define and strictly type

Maybe we could make meta.docs.recommended a union type? Perhaps rename it to something like config(s) or recommendation(s)?

Sent #8364 as reference.

strict-boolean-expressions also has some weird defaults that could be stricter:

  "@typescript-eslint/strict-boolean-expressions": [
    "error",
    {
      allowString: false,
      allowNumber: false,
      allowNullableObject: false,
      allowNullableBoolean: false,
      allowNullableString: false,
      allowNullableNumber: false,
      allowNullableEnum: false,
      allowAny: false,
      allowRuleToRunWithoutStrictNullChecksIKnowWhatIAmDoing: false,
    },
  ],

Also here:

  /**
   * The `allowDefaultCaseForExhaustiveSwitch` option is disabled and the
   * `requireDefaultForNonUnion` option is enabled to make the rule stricter.
   */
  "@typescript-eslint/switch-exhaustiveness-check": [
    "error",
    {
      allowDefaultCaseForExhaustiveSwitch: false,
      requireDefaultForNonUnion: true,
    },
  ],

And this:

  /** The `capIsConstructor` option is disabled to make the rule stricter. */
  "@typescript-eslint/no-invalid-this": [
    "error",
    {
      capIsConstructor: false,
    },
  ],

And this:

  /**
   * The `args` option is set to `all` make the rule stricter. Additionally, we ignore things that
   * begin with an underscore, since this matches the behavior of the `--noUnusedLocals` TypeScript
   * compiler flag.
   */
  "@typescript-eslint/no-unused-vars": [
    "error",
    {
      args: "all", // "after-used" is the default.
      argsIgnorePattern: "^_", // Optional, this line makes the rule less strict, but is idiomatic
      varsIgnorePattern: "^_", // Optional, this line makes the rule less strict, but is idiomatic
    },
  ],

Oh @Zamiell just looking at those now: none of those are in the recommended, strict, or stylistic presets. If you think we should enable stricter options for them by default and/or add them to a preset that'd be a separate issue.