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.
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.