One of the ground rules for the old exception specifications was that it had to be possible to link code compiled at different times. Which meant that there might never be a moment when the compiler had access to all the source code. And, given that most code did not have exception specifications, the only way to enforce them at compile time would have been to require them on all functions.

I didn't follow the development of noexcept, so I can only guess at the motives. By and large, there were three complaints about exception specifications that I am familiar with: (1) by requiring stack unwinding when a no-throw specification was violated, they often caused worse performance (or, at least, didn't allow an optimization opportunity); (2) generally, the important question is whether a function might throw, not which exceptions it might throw; and (3) the rules around when exception specifications affect a function's signature -- e.g., does a pointer to a function have to match the specification exactly? -- were convoluted. I think it was reasonable for the Committee to focus on those issues.

A possible solution would have been optional static enforcement of exception specifications plus fallback on the existing dynamic enforcement.

Existing unmarked functions would be expeced to possibly throw everything, while functions with throw specifications would be statically checked.

You can call the later from the former, but to do the reverse you need an explicit try/catch. Some form of throw(auto) would enable automatic deduction of exception specifications for e.g. template code.

Dyanamic exception specifications will be removed fron the language in c++17, so the synax is open to be reused for such a feature in the future.

The problem is C code. You know it won't throw, but there will never be any exception specification on it.

The "nothrow" is not part of the function signature, probably in order not to break retro-compatibility. Without this, "nothrow" cannot be enforced reliably at compile time. And I think they don't want to add a new sort of undefined behaviour if a function from a linked module doesn't respect the nothrow promise at runtime.

You are right, even nothrow doesn't fix the weirdness with signatures. However, nothrow allows a program to change behavior based on whether a function it will call will throw exceptions. That wasn't available under the old exception specification mechanism.