Similar to what you did in test5, I think it'd be helpful to comment on the return line itself whether NRVO is (done|possible|impossible). E.g.
return x; // NRVO is impossible
or
return x; // FIXME: NRVO could happen, but doesn't
or
return x; // NRVO happens
Your existing comment "No NRVO" is ambiguous — you mean it doesn't happen, or it can't possibly happen? — and makes me think just a little more than I ought to, because I have to skim the code and figure out which variable(s) and which return statement(s) we're talking about.

(I can see it being arguable whether the comment should go on the return x; or on the X x;. Me personally, I'd put it on the return. But I don't care enough to argue if someone thinks it should go on the variable definition instead.)

E.g. here, IIUC, I would comment this as

return x; // NRVO happens

I have been thinking on "sorting" variables within the scope to get the optimal NRVO condition (right after seeing test2), but didn't come up with anything =(

I guess that it's not legal at all, because initializing constructors (unlike copy/move constructors) tend to have meaningful actions (starting a timer, etc.), and many things will break badly if we will shift the declarations as we want.

Serendipitously, I just ran into almost this exact scenario in D120180, where C++20's reverse_iterator wants to do basically

{
  _Iter __tmp = current;
  --__tmp;
  if constexpr (is_pointer_v<_Iter>) {
    return __tmp;
  } else {
    return std::move(__tmp).operator->();
  }
}

and so we want NRVO on __tmp in the former case but URVO in the latter case. Of course in that specific case, we "want NRVO" only when __tmp is a pointer and thus NRVO doesn't apply anyway because pointers are returned in registers. But it would be nice to have a test case for as-close-as-possible to that pattern, if you don't mind adding one.