Thanks, that wrapper solution is just the thing!
I didn't find a way that move semantics would help with the argument case; the temporaries still go out of scope before data can be moved in (unless one uses a wrapper function, a patch, or writes their own generator).
Given when a wrapper function is not used that the misbehavior is (a) severe, (b) undocumented, and (c) not reported by compilers and implementations, my personal opinion is still that this is a bug.
The standard should clearly state that passing temporaries to a generator or defining temporary generators is illegal or at least undefined.
However, if generators executed eagerly, it would prevent a wide class of these memory corruption errors.
Move semantics may help address when generators themselves are defined as temporaries.
This to me reads like a great argumentation to put into a paper, that can be submitted for inclusion into C++26 or 29. If we have a known-bug-inducing current setup, that is not used much, that we can then still fix and have working in C++26/29, it would make sense to write a paper & to see if it can be seen at Austria - or shortly after. Teaching everybody "generator is kinda broken and you need to define this wrapper function" seems counterproductive, when we can propose to change "suspend_always" to "suspend_never" in one location and fix it for everybody.