I do agree noexcept has gotten a bit problematic, though I have no
opinion on the proposal presented here. I do want to grab this
opportunity to say that I find it pretty ridiculous that to reap the
benefits of noexcept I have to mark the entire call chain all the way
down noexcept though. If you don't? Yay, free invisible exception
handlers (That I don't want) in the final assembly! It's just not
practical to have to do that, in fact, on some implementations the C
standard library functions aren't noexcept like the standard says they
should be (Such as with the mingw-w64-headers), so it is physically
impossible to avoid the exception handlers if you want your program to
do anything useful at all (Because ultimately you have to call C
functions sooner or later, and you know what happens if you call a
potentially throwing function from a throw() one).

I do want to say I'm excited for
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3166r0.html
but it seems to also not fully address this issue with noexcept
unfortunately. I really wish C++ functions were throw() by default
sometimes like in other languages so we didn't have to deal with this
mess, although that will never happen due to breaking existing code by
this point. At this rate, I'd much rather deal with exceptions that
are brittle and harder to use like Java checked exceptions than with
an exception system that silently inserts extra code into your
programs if you don't obsessively mark everything noexcept. As it
stands, the former would annoy developers greatly, the latter makes
everyone slap -fno-exceptions onto the codebase and fragments the C++
world into nonconforming dialects, because it is a problem if you work
on a very low level codebase where every tiny change in the compiled
assembly matters greatly, such as the JVM.

Whew, that was quite a rant, but it was something that I find pretty
annoying. Hope you all don't mind.

best regards,
Julian