The problem is which modern C++ projects?

Android source code is definitely not one of them, and yet Google as ISO C++ contributor should know all about modern C++, right?

Ah, what about Microsoft and their UWP code samples for C++ developers, or the C++/WinRT based libraries?

As advocates from C++ Core Guidelines, surely those samples will be perfect examples from modern C++, right?

Or what about Bloomberg, with heavy contributors like John Lakos?

Maybe they are still in the process of adopting C++11 and C++14, while writing a book about language adoption issues.

I like C++ a lot, but we really need a compiler switch to turn off compiling Vintage C++, it would be marvelous.

Every single codebase you have just cited here (except for the nebulous "advocates from C++ core guidelines") is older than the Rust language. Look at high frequency trading code or maybe recent game engines for good C++ projects - I don't know if any of these are open source.

I 100% agree with breaking C compatibility, breaking ABI compatibility, and turning off vintage C++.

C++/WinRT is from 2015.

C++ Oboe SDK for Android was initially released in 2018.

Android Games Developer SDK was just released last month.

What game engines? Lumberyard , Unreal and Godot certainly not.

Vulkan C++ bindings from Khronos or Dawn for WebGPU? Also not.

The only modern C++ I can find in real life are at CppCon and C++Now talks, and books promoting it.

Even Bjarne Stroustroup has recently on a interview mentioned how he is disappointed how C++ Core Guidelines keep being largely ignored by the community.

There is even, yet again, a paper from him trying to advocate for better C++ on the next C++ mailing.

C++ is definitely better but it's still not memory safe. Compared to Rust, you still have little tracking which thread has access to which variable at which time. Even in modern C++, you still have to care about iterator invalidation.

It's far from done, but the GCC static analyzer actually can find iterator invalidation!

Some of it. Because a sound analysis would throw FPs up too frequently, they make the logical decision to use an unsound analysis. This is helpful, but cannot prevent the entire class of issues.

Having no instances of new or delete does not, in any way, prevent the entire class of memory vulnerabilities. Running off the end of a buffer when processing untrusted data is just as easy. Heck, you can still absolutely get UAF issues even if you never allocate on the heap simply by holding a reference to a stack allocated object past its lifetime. Given how weird the rules around lifetime extension are, this can happy is really really subtle ways.

C++11 is not a safe language. Not even close. It is much much much better than what came before, but it is not safe.

While unique/shared_ptr alleviate some of these issues the STL is still full of UB though, and that can’t be fixed easily.

What proportion of C++ code is "modern"?