This seems reasonable, though because methods with overloaded names aren’t quite first-class w.r.t. other features, you couldn’t use an unhidden with-defaults approach at all if you already have, say,
def makePerson(first: String, last: String) = ???
def makePerson(entry: DbEntry, allowPartial: Boolean = false) = ???
Starting from that, you can’t even use the mechanism. Although you could if you allowed explicit unrolling of defaults (but it wouldn’t work for more than one default argument):
@unrolledDefault
def makePerson(entry: DbEntry, allowPartial: Boolean = false) = ???
// becomes
def makePerson(entry: DbEntry, allowPartial: Boolean) = ???
def makePerson(entry: DbEntry) = makePerson(entry, false)
But that can be done manually in the cases where it’s needed, trading off some source compatibility for binary compatibility.
It also won’t interact well even as is in hopefully-rare cases where an opaque type overload was already present.
opaque type Passport = String
def makePerson(first: String, last: String, passport: Passport) = ???
def makePerson(first: String, last: String) = ???
But this is a weird enough edge case that I don’t think it should derail the idea.