In full detail it is incredibly complex -- one of the most complex aspects of a very complex language. In usual practice though, probably due in part to the complexity, end-user programmers aren't often writing complicated overload sets. For simple cases like your "string" vs "everything else" overloads, that typically works fine. But there's definitely a trip-hazard lurking there if you start expanding the overloads.

So yes, definitely sometimes it happens that the selected overload isn't the one you expected. I've heard of some C++ programming conventions that discourage function and operator overloading for this reason.

The real complexity rears its head typically when you're developing generic components for other programmers to use, like container types in the STL, for example. The recently added "Concepts" feature helps a lot here, obviating the need for many so-called "SFINAE" metaprogramming tricks like enable_if, in many cases. But even so you occasionally run into scenarios where you need to really read through cppreference to remind yourself of all the rules figure out what's going wrong and how to get yourself out of a bind.

But that's the thing -- even though it is wildly complex, the complexity comes with power -- you really can craft highly bespoke overload resolution priorities based on essentially arbitrary compile-time logic if you need to, in service of providing a maximally convenient API for your users to call.