On Mon, May 27, 2024 at 11:51 PM Tiago Freire via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
What you are doing is way too complicated for what is actually required.
 [...]
And the condition that seems to best maximize this is, "copy elision of a named variable is guaranteed if its lifetime does not overlap in any scope with another object that could also possibly be returned".

It is a simple sentence to change in the core language, it allows you to do everything you want in all circumstances that are possible, you don't need to write code differently, it doesn't do anything that the compiler isn't already allowed to do (but decides not to), you don't need to add a new library features or functions or keywords or hoops to jump, no gotchas, you can't do it wrong, you are able to express intent in a coherent manner and allow the compiler to do its job,
It always works and everything benefits regardless of it being immovable/uncopiable or otherwise. That's it, you don't need anything else.

I agree with you on the part that volatile opcode arrays that you can jump into are no-go for standardisation (it's nice for a prototype, but that's different from standardisation). I also agree that the sentence you write above solves the NRVO issue. However, before I wrote (and the reason why I wrote) the @-notation is that there were additional issues mentioned on the list. This includes returning char arrays and similar. Now, you might say that it can be solved as a separate issue, but there's a solution that solves both. Besides these, we agree I think.

Thanks,
-lorro