Things like this have been discussed many times, going back years. Given that it hasn't already happened, any successful RFC will need substantial motivation and rationale sections. There're plenty of previous concerns to address.
One alternative, then, would be to use a different marker. For example, there's the Swift-inspired .SomeVariant, as I've mentioned before (Allow wildcard while destructuring structs - #11 by scottmcm).
Having no marker needs much stronger rationale, IMHO, as it loses the "when I see a name outside a method call I know I can find the use or definition for it in the file".
I suspect that this, for an individual feature, isn't going to happen. You opt into editions, sure, but not to individual features. That way there's a very small number of dialects. It's absolutely essential to avoid a combinatorial explosion, both for the test matrix and for human understandability. If this got its own opt-in flag, then every future contentious feature would propose adding them too.
Ideally, assuming it's a desirable feature, it'd be turned on in all editions when stabilized. (As that's the default preference for all new features.) You say that unwanted behaviour here is "almost impossible" -- does that mean that it's possible for this to be a breaking change, and thus could only be enabled over an edition? Or is there a way it could be defined to not be breaking? And if so, what implications does that have for inference stability over the addition of extra items in the future?