I fully agree with you, but my point is that until Rust achieves a certain parity with mobile OS C++ tooling the "good enough approach of C++14 and C++17" improvements will prevail, even among those that would rather use something else.
Given myself as example, in spite of all my rants about security that you well know, I still use C++ as my portable business code between mobile platforms.
However I always compile with all warnings as errors, fully embrace C++ STL types for safe programming and do regular static analysis, exactly to minimize as much as possible the errors that might still miss my attention.
If I would be focusing just in a single platform, then I would surely choose between Swift, Java and C# respectively.
No, there aren't. Empirically, modern C++ projects are not memory safe. Maybe when you qualify it with this:
> At least when using it alone or in small teams that value safety.
But I suspect the reason it looks that way is actually this: Projects that are developed alone or with small teams tend to be less important projects that people don't try to attack and/or find memory safety problems in. The lack of people actively looking for memory safety problems makes it look like C++ projects are safe, but in reality they aren't. If solo/small team projects in C++ had anywhere near as many people looking for holes as big ones like browser engines, then they'd fall over too.
I don't have any hard statistics for this, but given the consistent memory safety track record of C++ projects I think I'm more likely to be right here than wrong. I've written small projects in C++ and I don't think they're memory safe, even though I don't know of any areas where they aren't. I just know what the statistics are.