I don't think it's necessary to cover every possible combination of algorithms/reductions in one function. At some point, you will just need to use a custom loop, and that's fine.

I was refactoring code at my workplace the other day, which looked something like this (simplified):

std::vector<int> values = ... ;
auto isMyFavorite = [](int i) -> bool { ... };
int* myFavorite = nullptr;
int* minEven = nullptr;
for (int& i : values) {
if (!myFavorite && isMyFavorite(i))
myFavorite = &i;
if ((i%2==0) && (!minEven || i < *minEven)
minEven = &i;
}

It's not a great example. In your transformation below, you mention find_if, but that's not exactly what you have here. You don't quit early when you have found an isMyFavorite element, so you're finding the last element matching the predicate in the range. That's not what find_if does, and it may be a lot slower.

You can already break this up into:

std::ranges::find_if(values, isMyFavorite)
std::ranges::min_element(values, values | std::views::filter(even))

You're saying that you would like to do it in a single pass, but have you actually measured whether that would improve performance meaningfully in any scenario? That's what your idea hinges on at the end of the day. We have a perfectly fine way to express these operations, it may just be that a single pass is faster in some scenarios. Without that performance benefit, I'm not seeing any motivation for the idea. It is more complicated to cram several algorithms into one mega-function than to keep them separated.