It should not. Equality should mean equality. I don't see why this should be so distasteful.
First, unnecessarily requiring both sides to be of the same type causes problems with (for instance)
signed char c1 = -1; unsigned char c2 = 0xFF;
where c1 != c2, but they compare equal if either is converted to the type of the other. So this requirement leads to much extra complexity with common_type and so on.
But I'm not requiring both sides to be the same -- only related. Also, this behavior is well defined and preserves the semantics of equality. The common type of c1 and c2 is int -- it doesn't have (and often isn't) one type or the other. int(-1) and int(255) are certainly not equal. Admittedly, you run into overflow issues with large enough integer types, but c'est la vie. There are always implementation limits that confound our best efforts to formulate accurate and meaningful semantics.
"test" == std::string( "test" ) == "test"
but "test" may well not compare equal to "test".
Do you mean to say that the character pointed to by the first "test" may not be the same as the character pointed to by the second? So: "test" == "test" might be false? That could be the case, but that's an issue with the language's resolution of an operator for ==. Comparing pointers is not the same as comparing strings. If the type of "test" was something other than "const char*", say, constant_string, you could expect different behavior.
Third, because of the preceding two points, std::find does not, in practice, require same type or equivalence.
But it does, in practice, require equality comparison, which I am suggesting should have a more precise definition.
This leads people to use it with types of the form
struct X { int key_; ... value_;
bool operator==( int key ) const { return key_ == key; } };
Now... this is where you legitimately may claim that these people are wrong.
Generally yes, but I think I see how to generalize the relationship between X and int that would satisfy the semantics of an equivalence relation. Actually, I think I see how to do this for all types using this comparison. I'll have to think on this.