Methods such as these for C and C++ are interesting, and needed, but only solve a part of the problem.
As others have noted before, they do little good because they're opt-in. I think there's a bit of nuance to that which needs to be explored though, as I think it's less a problem that the extra checks are opt in, and more a problem of how we use and categorize libraries.
As long as we encourage dynamic and static library inclusion (and why wouldn't we, it's how we build upon the work of others), every language has a problem similar to how C and C++ are opt-in and you can't easily control the code you include or link. If you load openssl from Java or Rust or Go, you might have some benefit from a well defined API layer, but ultimately you are still beholden to the code openssl provides in their library.
Just as one of the real benefits of Rust or Java or Go is not necessarily that the code is completely safe, but that weird unsafe behavior usually requires special escape hatches which are easier to audit, what we need are ways to categorize the code we include, no matter the language it comes from, with appropriate labels that denote how strong the safeguard guarantees it was compiled with are and of which type, so we can make easier and better informed decisions on what to include and how to audit it easily when we do.
This applies to including something written in Rust as well. If someone is writing something in C++ and wants to include a library written in Rust, that it's written in Rust is only part of the picture. It's equally important to how often (as a total and as a percentage of code) the safety checks that language required (or that the developers opted into) where escaped in that library.
If the choice is a Rust library with 95% of the code in unsafe blocks or a C++ library that opted into multiple different safety checker systems and has almost no escapes from those requirements, Rust is not providing any real safety benefits in that situation, is it? What we need is better information exposed at a higher level to developers about what they're opting into when they use third party code, because we can all control what safety mechanisms we use ourselves, so that's mostly a solved problem.