The usage of converting constructor in optional only shows to me that we
have not established a good criteria for telling when having a converting constructor is a good idea. I always used to think that if only you are not loosing any information, it is safe. But in the case of optional I can see that even then it can have some negative consequences. Perhaps it is the way the language is designed that is wrong: that you either allow this conversion in every possible situation or never at all.
Oh, c'mon. Cheer up. Things are not as gloomy, are they. :-) Here the subtlety (IMO) lies in how reasonable it is to add information. Namely, as I indicated, if we bring T into the optional<T> fold, then we apply optional<T> rules to T, i.e. apply t to optional<T> conversion. Say, we have a mandarin and an orange. When we bring the mandarin to an orange factory, then mandarin-to-orange "conversion" is applied and for all purposes mandarin is a "small orange". Outside the factory, when we compare mandarin to orange, it is not immediately clear what should be treated as what. If we apply mandarin-to-orange "conversion", then it'll be "small orange vs. big orange". If instead we apply orange-to-mandarin "conversion", then it'll be "sweet mandarin vs. sour mandarin". Given the library writer does not know, which it is, we ban it. Still not convinced? I've spent all munition I had. :-)
I responded to this in another thread. We diverged too much from the original issue.