At least historically, these two lint sets tend to trail best practices. I.e., we've used a published recommendation in effective dart as a reason to add a lint to these two sets.

Though for some items we've adjusted the lint set to prep best practices for upcoming language changes (i.e., dart-lang/sdk#51221).

Post feature, I'll want a "no local _ variables" as a core lint.

The only places where _ names make sense are parameters (which you need to have for the signature, but don't need to reference the value of) and destructuring/pattern matching, and pattern matching has internalized _ already.

If you write var _ = 42;, you're missing some point somewhere. It's likely a mistake. That's enough for me to want a core lint to prevent it.
(If you write int _(int x) { return x; }, you're seriously missing something.

I don't know how I feel about avoid_renaming_method_parameters wrt. _. I'd personally be fine with using _ in an override, but I can see why someone using that lint may disagree.
I'd definitely be fine with an override using a real name where the superinterface used _. It's not a renaming when it started from nothing. It's just a naming.

Pre-feature, guiding people away from using _ as a variable name and referencing it is a good idea.
I'd just enable that as a language warning, no lint needed. We're going to change the language in a way that will make that code stop working. That's basically a deprecation warning.

Thanks!

I don't know how I feel about avoid_renaming_method_parameters wrt. _. I'd personally be fine with using _ in an override, but I can see why someone using that lint may disagree.

This is in fact how it's currently implemented. And as of dart-lang/sdk@4a7db83,

I'd definitely be fine with an override using a real name where the superinterface used _. It's not a renaming when it started from nothing. It's just a naming.

this too.