Could the entire ResultType column be done away with, being replaced everywhere in code with "auto"?
No.
In other words, the Concept we are looking for is that the type supports the operation, but we don't necessarily care about the result type except that it also supports the subsequent operations required.
There's been extensive research work in this area, and there's no easy fix if you want to say something meaningful. You'd need to make the result an associated type and specify its required relationships with the input types.
There is a related issue: even if the types are related, and the concept well specified, actually programming with them isn't going to be easy. To consider a trivial example, if T*T isn't a T, then one can't even evaluate a polynomial approximation to the function: result = A + B* T + C * T^2 + D * T^3... to give a concrete example, the root finding algorithm that started this thread uses a polynomial approximation to the function to greatly speed up finding the root (we can find the polynomial approximation and it's root algebraically once we have evaluated enough points in the function). It's this insight that makes the algorithm converge so rapidly compared to the alternatives, but requiring that T*T != T breaks the underlying assumptions not only in how it's implemented, but in how it actually works algorithmically. That's one of the reasons I suggested a forwarding wrapper. Hopefully this explains the issues, John.