Mathematically, conj() and proj(), like the transcendental functions, are complex-valued in general but map the (extended) real line to itself. In fact, both functions act as identity on the reals. A typical user will expect conj() and proj() to preserve this essential mathematical property in the same way as exp(), sin(), etc. A typical use of conj(), e.g., is the generic scalar product of n-vectors:

template<typename T>
inline T
scalar_product(size_t n, T const* x, T const* y) {
  T result = 0;
  for (size_t i = 0; i < n; ++i)
    result += x[i] * std::conj(y[i]);
  return result;
}

This will work equally well for real and complex floating-point types T if conj() returns T. It will not work with real types if conj() returns complex values.

Instead, the implementation of scalar_product becomes either less efficient and less useful (if a complex result is always returned), or unnecessarily complicated (if overloaded versions with proper return types are defined). In the second case, the real-argument overload of conj() cannot be used. In fact, it must be avoided.

Overloaded conj() and proj() are principally needed in generic programming. All such use cases will benefit from the proposed return type requirement, in a similar way as the scalar_product example. The requirement will not harm use cases where a complex return value is expected, because of implicit conversion to complex. Without the proposed return type guarantee, I find overloaded versions of conj() and proj() not only useless but actually troublesome.