I think in some linters this is called "nursery". Though nursery can also refer that they are unstable to enable. So it's little bit different than having rule that should be stable, but it's not enabled by default in recommended set.

• Biome https://biomejs.dev/linter/rules/#nursery "New rules that are still under development."

  • Nursery rules require explicit opt-in via configuration on stable versions because they may still have bugs or performance problems. They are enabled by default on nightly builds, but as they are unstable their diagnostic severity may be set to either error or warning, depending on whether we intend for the rule to be recommended or not when it eventually gets stabilized. Nursery rules get promoted to other groups once they become stable or may be removed.

• Clippy https://doc.rust-lang.org/clippy/ "new lints that are still under development"

The big issue I see here is that we don't usually decide upon what the recommended set should be in the next major until we're pepping for the next major.

We might have some ideas about new rules and whether or not they make a good recommended candidate - but we don't usually provide much more thought than that.

Here's the Discord thread: https://discord.com/channels/1026804805894672454/1217588154710622271/1217896050745147423

There was some confusion as to why no-array-delete wasn't recommended and it wasn't easy to see that it was a new rule that likely would be considered for inclusion in the next major, leading to questions being asked, so that's the problem I suggested this to solve 😌

Yeah for sure - I get the idea!
I'm just explaining that it would be a big change in our workflow for us to build this.

Right now our workflow is that we don't fully consider changes to the recommended set until we are preparing for the next major - at which point we generate an issue with the list of rules and we go through each rule to decide (a) if it's in the list - should it stay in the list and (b) if it's not in the list - should it be added.

Essentially we write everything out and we open it for community discussion and then we make some decisions and commit them for the major.

So you can see how trying to maintain a list before the major is a shift in things - we need to build out this issue and remember to keep it updated as we merge new rules in so that we don't lose track of anything.

There's also the issue of #8695, that we leak internal meta.docs types. I'd think we'd want to wait until that's resolved before adding yet another option to these types (previous addition: #8364).

But, following that, I'd be up for values likes "recommended-prospective" and "strict-prospective" (or something with fewer characters?). As long as the docs are very clear on what they convey.