As someone who does not do modern C++ development, the problems they bring up seem to largely be of the flavor that positional parameters work poorly with default values in C++. The reason being that all default values do is give you the ability to elide the last N arguments. This is much worse than automatic selection of the correct overload based on the supplied arguments.
However, it seems to me that you could entirely resolve this problem by having true keyword arguments and default arguments must be keyword arguments; they can not be supplied positionally. If you then want some syntactic sugar in your API, you can then do what the author suggests as a solution to default values and supply variants that explicitly pass "defaults" to the master function.
Keyword arguments allows defaults while still allowing exact control over the arguments, exact control over the "overload selected" without explicit variants, and the ability to supply explicit variants if you want API ergonomics. The only downside I can see (relative to the solutions presented by the author) is that you have to write some extra argument names when passing non-default values to any variants that do not trivially pass them through, but that is a pretty minor cost especially with a IDE that can autocomplete the keywords, and it provides extra useful documentation to the maintainer and client, so it is not even all bad.
I don’t use Python much these days, and Rust and JavaScript don’t have equivalents, so I haven’t thought much about this, but my gut feeling is that there’s probably never a good reason to support taking an argument by both position and keyword, that it should instead be one or the other. But as I say, I haven’t meditated on this. Curious if any popular linting tool has rules to detect any of these three classes of argument (… and also args and *kwargs).
In the Julia language overloading only considers positional arguments (which must be given positionally) with keyword arguments entirely separate (and they must be given as keyword arguments).
However, it seems to me that you could entirely resolve this problem by having true keyword arguments and default arguments must be keyword arguments; they can not be supplied positionally. If you then want some syntactic sugar in your API, you can then do what the author suggests as a solution to default values and supply variants that explicitly pass "defaults" to the master function.
Keyword arguments allows defaults while still allowing exact control over the arguments, exact control over the "overload selected" without explicit variants, and the ability to supply explicit variants if you want API ergonomics. The only downside I can see (relative to the solutions presented by the author) is that you have to write some extra argument names when passing non-default values to any variants that do not trivially pass them through, but that is a pretty minor cost especially with a IDE that can autocomplete the keywords, and it provides extra useful documentation to the maintainer and client, so it is not even all bad.