https://github.com/mongodb/mongo/blob/22a595fbef4d023002b3c74d529368fcc4dbb196/src/mongo/logger/logstream_builder.h#L203

Among the many overloads of LogStreamBuilder::operator<<,
we have this catch-all.

template <typename T>
    LogstreamBuilder& operator<<(const T& x) {
        stream() << x.toString();
        return *this;
    }

The problem is that it's not constrained to T for which x.toString() exists.
So it matches types it shouldn't, and they then fail to compile. It can also hide other operators that should be good matches due to implicit conversions or base classes.

We could probably do much better here.

Maybe if x.toString() is valid, we allow this into the overload set.

Otherwise, if std::ostream<<x is valid, we do stream()<<x, which a lot of the other overloads do.

Otherwise, LogStreamBuilder butts out and doesn't provide an overload for the operator. There's still a chance for x to define its own operator<< for LogStreamBuilder to be found by ADL, but that's not LogStreamBuilder's concern.

This strategy would reduce user surprise, and reduce the number of overloads in LogStreamBuilder from its current (insufficient) 24 down to something like 3.