Aside from whatever Walter's reasoning is, there are existing constructors
in the wild which use

    this(S)

It's not clear to me how it actually works now; but I think it would be interesting to explore that first; because I think the solution for this case being reinterpreted as move-constructor is related (and equally solved).

This function receives it's arg BY-VALUE; so it can happily accept an r-value... but it's not actually clear how this function receives an lvalue even in today's language?

In order for this function to receive an l-value by-value, it must first make a copy to supply as the function's argument (but the function is allowed to internally mutate its argument)..

...but isn't this said to be the copy constructor?

This already looks like a chicken/egg problem in today's language... how does it create a copy of an lvalue to pass the argument to this function without calling this function?

Whatever answer exists that makes this work equally makes the case work where this is reinterpreted as a move-constructor.

The only explanation I can imagine is; because this ISN'T actually a copy constructor, the compiler determined that it was appropriate to synthesise one (which would be to just copy all members), and so an implicit copy constructor DOES actually exist beside this constructor, you just didn't write it.

And assuming that's the case, when this becomes reinterpreted as a move constructor, the code remains perfectly correct!

I don't see how elevating this declaration to a move-constructor actually changes the semantics at all... I don't think it does? I think this function ALREADY IS A MOVE CONSTRUCTOR (at least; it's an rvalue-constructor, which is the same thing from a semantic perspective); it's just working with an inefficient calling convention.

Move semantics as proposed simply improve this code, no?