I branched eurydice5717 and he in turn made two branches with some nice solutions.

please feel free to fix it if you like.

Answer given in the other comments in the other flow: it is not a matter of 'execution policy' but a matter of the nature of the 'Input IT' in 'std::none_of'. Without using the ExecutionPolicy parameter, std::none_of uses 'LegacyInputIterator' (see https://en.cppreference.com/w/cpp/algorithm/all_any_none_of). In this context the 'LegacyInputIterator' CANNOT be decremented nor 'n-added'. Thus, parsing collection from begin() to end() by incrementing the iterator (meaning using '++it' only) is guaranteed. See https://en.cppreference.com/w/cpp/named_req/InputIterator

Actually IMHO it is not a matter of 'execution policy' but a matter of the nature of the 'Input IT' in 'std::none_of'.
Without using the ExecutionPolicy parameter, std::none_of uses 'LegacyInputIterator' (see https://en.cppreference.com/w/cpp/algorithm/all_any_none_of).
In this context the 'LegacyInputIterator' cannot be decremented nor 'n-added'. Thus, parsing collection from begin() to end() by incrementing the iterator (meaning using ++i only) is guaranteed.
See https://en.cppreference.com/w/cpp/named_req/InputIterator

Ah, I get it. So, its a "value" type that when copied, copies a boxed reference. Nice. BTW... on my prior question, how do you know that the execution of none_of is sequential? Should we not pass std::execution:seq?

Took me a while to understand... If you pass directly the 'par' struct in the std::none_of, actually there is a copy and when you return the current 'par' in the main function will always have a count at 0 (as by default)...

"Can you spot why we should use 'std::ref(par)' and not just 'par' ?"

No, I am pretty new to modern C++. I am confused by the reference material on the std::ref and the reference wrapper, and why it is needed

(I edited above to remove my understanding of std::ref, that was wrong no matter how I tried to make it work)

Do we know the execution policy is seq? I find it very hard to determine from the reference material

You may make it 'if then else' as well... Doesn't really matters and I understand your concern.
This one relies to a youtube video of 'The Cherno' reviewing code on rendering, std::any_of will make an early exit on the scan (if condition is met) while if we used std::accumulate, it would be nicer but it would always scan the entire range of values.

')(' should fail

Great answer. I have a pet peeve about nested ternary, but this is a nice one

This code fails if you add a simple inversion test (')(');

When the algorithm does not need the i index value, I prefer to use range based for loop, it makes the code more readable.

The big thing I had in mind was to do an else-if on the second conditional since it will only be valid if the first one fails. Also, prefix increment/decrement is a tiny bit more efficient.