1. Nested templates closing brackets conflicting with `>>` operator, necessitating `> >`. This was fixed in C++ 11.
2. Syntax for declaring an automatic variable conflicts with the syntax for C function type: `Thing mything();`.
In all other cases in my experience, investigating the rationale behind a particular quirk has led to a fairly interesting reason; a difference between the heap and the stack, say, or the language giving you the option to not do some work that may be expensive and unnecessary. For example, beginners often are surprised and annoyed that `remove_if()` doesn't actually remove anything and they need to call `erase()`. But most STL algorithms work on a pair of start and end iterators and you can simply work with the new "past-the-end" iterator returned from `remove_if()` allowing you to combine or omit the calls to `erase()`. This is certainly quirky but its not "mental clutter": there actually is a fairly interesting reason for the API being designed this way, rooted in the zero-overhead principle.
In my experience that has been the rule, not the exception - taking the time to understand the "why" behind a given quirk usually results in being forced to admit to yourself, "yes, I see; that is the only way it could have been designed as a zero overhead abstraction. The 'simpler' alternative I had in my head would require some overhead to implement." I think that's the reason why so many people on this thread who have read "The Design and Evolution of C++" change their mind and come away with praise for the language - because it lays bare the logic behind many of those design decisions.
I would be interested to hear which quirks in C++ you view as mental clutter and/or design mistakes. As far as I can tell, most of C++'s usability problems come from it being too carefully designed and too backwards compatible. And after witnessing disasters such as Perl 6, I'm not sure "backwards compatible" is really a "mistake" per se.
C++ goes completely against the principle of least astonishment.There is a huge amount of mental overhead to reading and writing code in it. All that distracts you from the problem you're actually solving and directly translates into long development times, defects, and maintainability nightmares.
I don't think the complexity of the language ultimately justifies the goals it's trying to accomplish.
OOC, how long ago did you witness this "disaster"? Perl 6 is doing very well, thank you.