Congratulations on your first proposal!
I'm -1 on this idea, because I suspect it will add extra pitfalls for projects when evolving their APIs. You've called this out already in the "source breaking change" note, and I think that's reason enough to not go down this road.
One reason this can happen in real projects is as part of library API evolution. As an API grows, you will likely grow new methods that enable extra flexibility. This flexibility will manifest, at least some of the time, in being able to pass new arguments to existing functions. Right now it is always possible to avoid the ambiguity while adding
Optional parameters by refusing to give them a default value. With this change, evolved parameters may never have an
Optional type, even when that type is semantically meaningful, as they will encounter this ambiguity.
I'm disinclined to introduce ambiguity of this form, so I'm -1 on the proposal. If it were accepted, I'd want to argue for warning at the call site, not at the compile site, as the call site should take action to disambiguate which call they want.