In order to figure out why a template constraint failed, you generally have to look at every overload (or most of them anyway), and with more complicated constraints, simply saying which of `e1 && e2 && e3 && ...` failed probably wouldn't be enough (especially when `||` gets involved), but it would be better than what we have now. In either case, we probably need to find a sane way for the compiler to tell us which parts of a constraint failed, but unfortunately, for that to be useful at all, you have to see _all_ of the overloads, so you could end up with some really long error messages (especially if it's telling you which part of each template constraint in every overload failed). That would be particularly bad with a function like `find` which has a lot of overloads.

One approach that we should at least consider is to make it so that the function in the public API has no overloads. Either it's a template (like with `map`) or it's a templated function, but in either case, it has a template constraint on it which covers all of the overloads for the function that you want with one general constraint. Then all of the different overloads are internal (either by nested functions or by private ones appended with `Impl` or similar) with their own template constraints for differentiating between them. So, assuming that all of the template constraints are correct, all the user ever sees is the simplified one. I don't know if we want to make this approach general policy or not, but it might make dealing with some functions like `find` easier when template constraints fail.