For me this is not a good change, as it complicates specification significantly.
Also if you think your condition might hold just use std::ranges::includes.
For algorithm to check this seems like a bad idea, similarly how std::sort does not check std::is_sorted before running. 
If people think their array might be sorted they can check, not impose cost on every call. 
Beside that qualifying output requirements based on inputs would make every algorithm much more complex to understand. 

For example this can probably work fine, but why would standard bother enabling that? 
std::vector v{1,2,3};
int* dst = nullptr;
std::ranges::copy_if(v, dst, [](int){return false;});

On Sun, Sep 14, 2025 at 3:52 PM Peter Neiss via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

The std::set_intersection algorithm forbids overlap of the input ranges with the output range, but if first1 or first2 and result would be equal, the algorithm could still work(see cppreference for possible implementation).
This would allow inplace execution without memory allocation, which is a big plus.

26.8.7.4 set_intersection (wording)

replace: The resulting range does not overlap with either of the original ranges.
with: result may be equal to first1 or first2, otherwise the resulting range does not overlap with either of the original ranges.


PS: I am quite sure my statement is correct and I am not making a fool out of myself. Still confirmation of my claim would be great.


--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals