Quote Originally Posted by JohnW@Wessex
The point in my example was that the result is neither undesired syntax or even elegant syntax.
It just doesn't do what it first appears to do.
Therefore it is undesired syntax.

Quote Originally Posted by JohnW@Wessex
The actual code may not be as obvious as this, causing strange and hard to find bugs.
I prefer to stick with the philosophy of 'least surprise' and make operators work as much as possible to POD rules.
Ah, but in that case, you should be applying this rule as a general rule, not just one for operators. That is, when you want to return by value, return by const value. So, it is not so much about making "operators work as much as possible to POD rules", but about trying to design an interface that is hard to misuse.

The trade-off is that you then get an interface that might be slightly less flexible, but that is the same whether it is applied to operators or named functions. My preference would be to allow the flexibility, not only because it is in line with what the standard library already does, but also because I see the possible misuse as unlikely.