> While I agree in principle that we do not want unnecessary complexities,
> the proposal does solve immediate problems (code duplication is bad,
> right?) without too much learning overhead. So it looks good to me (from a
> user point of view).

All the benefits listed in the paper, including the avoidance of code duplication, can be obtained simply by adopting the new syntax to define non-static member functions, without changing or adding anything else to the standard.

Unfortunately, however, the paper is not satisfied with that simple fix. They want to add the following complexity to the language.

Quote from the paper: "The status quo is that all member functions are either static member functions or non-static member functions. A member function with an explicit object parameter [...] is a third kind of member function that’s sort of halfway in between those two. They’re like semi-static member functions. We’ll call them explicit object member functions due to them having an explicit object parameter. You can think of regular non-static member functions as being implicit object member functions. The high level overview of the design is that from the outside, an explicit object member function looks and behaves as much like a non-static member function as possible [...] But from the inside, an explicit object member function behaves exactly like a static member function." --end of quote.

It seems they are adding this new type of member functions only because they want to be able to pass the object argument by value, which is a trivial thing and hardly can be called a benefit.

Let's wait and see what the final adopted text will look like. I still doubt that the proposal in its current form will make it to the standard.

In recent years the trend has been to remove unnecessary complexities from the language.