That's not my experience as a C++ developer in a complex, cross-platform, application, which needs to:
1. interact with C;
2. operate with an event loop;
3. operate/interact with a GC;
4. interact with non-trivial system libraries (e.g. Direct3D, Vulkan, ...)
> In any case either of these is miles easier than satisfying the Rust borrow checker, unless you use the cop-out of (A)rc.
The borrow checker is indeed complicated. I'm not sure how you define "satisfying", though. As for (A)rc, it can definitely be interpreted as a "cop-out" or as delaying optimization until you actually have good reasons to believe that you need it.
I do not offer consulting but can refer you to people who do.
In particular most multi-threaded C++ code is incorrect, not because it is impossible to do it correctly, but because the standard tooling is too low-level, each third-party framework targets a different niche, and people who roll their own tend to hack it together.
I understand Seastar is supposed to do it somewhat correctly, so you could suggest to Mozilla that they switch to that.
Enforcing strong exception safety might require some thought, but it's definitely not "a research-level problem".
In any case either of these is miles easier than satisfying the Rust borrow checker, unless you use the cop-out of (A)rc.
Regardless, how the invariants of your objects are maintained in case of operation failure is something you should be thinking of regardless of the language.