I think you fail to understand what it means to evolve a language specification rather than breaking one.

I think given your obvious bias in both method and approach you should probably just plan on learning a new language every 2-3 years or so when what your ideas of the "best" way to do things changes and languges supporting the latest fad are developed. Probably, just avoid commenting on C++ altogether as it is a waste of your energy because it will quite frankly never do what you want given the aims and goals of the steering committee.

Out of interest, what do you feel are the solvable problems with exceptions in C++? The obvious one is exception specifications, which are probably best ignored.

While I agree they are frequently a pain, I'm unaware of any language which has really managed to do exceptions much better. I am happy to hear of examples however.

Double exception faults come to mind; C++11 did not even attempt to solve this problem, and just sort of brushed it under the rug. The solution to double exception faults is pretty straightforward: the stack should not be unwound until either the end of the exception handler or if the exception handler explicitly unwinds the stack. The downside is that it adds complexity to code generation and some overhead to functions with exception handlers, but the upside is that you have a far more robust exceptions system, and you have an opportunity to add a very nice feature that can help a lot with encapsulation: restarts.

Since you asked for examples, I'll point to the Common Lisp "conditions" system, which includes restarts:

http://www.gigamonkeys.com/book/beyond-exception-handling-co...

(I'll be honest here and point out that "handler-case," while simpler and more convenient, can still have a double exception fault; this is resolved similar to how Java resolves such things, which is to "forget" one of the exceptions. "handler-bind" is slightly less convenient but is much more robust, and does not have this problem.)