If we do add another use for it outside that clause we'd need to move it back again, so I'm not sure it's worth it.

Can't we just replace uses of decay-copy with the new auto?

Yes, that's what the "auto" paper did in the places where it is applicable. However, decay-copy and auto have some subtle difference, and the remaining uses are not obviously auto-able.

What are the differences? "auto" was pitched as "decay-copy in the language"...?

I think "auto" doesn't materialize temporaries per se (it just passes through an rvalue argument as an rvalue, thanks to "guaranteed copy elision"), whereas decay-copy always materializes a temporary from an rvalue, because it's pitched as a "real" function.

Oh, that's subtle -- thanks! Does that make a difference in the library?

Yes, which is why LWG asked for changes to P0849 so that it didn't replace all uses.

Ah yes, I see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0849r8.html#Does-auto-works-in-place-of-decay-copy-in-the-library-specification now. Thanks!

What about std::move(auto(x))?

std::move(auto(x)) can't be used, because it's an xvalue, while RAOs always return prvalues.

I think the uses of decay-copy in views::take and views::drop are doubtful. Apparently ((void) F, (void) E, T()) may be used instead, which means they return a default-constructed empty_view in those cases. However, it's not guaranteed that copy/move of an empty_view has no side effects, especially for program-defined specializations.

I think we've established that auto and decay-copy are not identical, so replacing one for the other could be changing semantics. Any such change would thus need an LWG issue.

There is also little support for moving the definition of decay-copy.