The first one also sounds a bit like -D_FORTIFY_SOURCE=2 in glibc which fortifies memcpy etc. Many Linux distros have had this enabled by default for years. (https://stackoverflow.com/a/16604146)
Agree the second one both sounds interesting and also quite disruptive to existing code.
_GLIBCXX_ASSERTIONS is slightly different because it uses the bounds information that is already available. The historical expectation is that operator[] doesn't perform bounds checking by default, you need to use the at(size_type) members for that. Hence _GLIBCXX_ASSERTIONS for opting in. It's basically a library-only thing, much easier to implement than source fortification.
- a bound checked libc++, which is not particularly exciting, libstdc++ has had _GLIBCXX_ASSERTIONS for a while for example. In fact it seems that libc++ has had it as well.
- clang warnings to flag potentially unsafe code plus fix-it suggestions to convert it to safer code using the bound checked libc++.
The later is quite interesting, especially the fix-it might make it easier to incrementally "harden" a large c++ code base.