Of course there will always be some issues somewhere. But, ignoring perfect memory safety, the issues are widely overblown, to the extent that I find manually managing memory a lot easier than dealing with GC once a project grows beyond a couple KLOC.

It's all about proper planning and code organization. Use pooling, central manager structures, etc. If it can be avoided, then do not allocate and free stuff in a single function like you would carelessly do with automated GC. Structure the data such that you don't have to release stuff individually - put it in containers (such as vectors or maps), such that you can release everything at once at certain points in time, or such that you can quickly figure out what can be released at central code locations (that's much like automated GC, but it's staying in control and retaining room for optimization).

I don't think "multiple distributed teams" makes the challenge any harder. You certainly want to (and I'm sure you easily can) contain each ownership management domain wholly in one team.

> You certainly want to (and I'm sure you easily can) contain each ownership management domain wholly in one team.

That doesn't work in enterprise projects with heavy dosis of consulting.

Purely anecdotally, I spend very little of my time thinking about what passes for manual memory management in C++.

For me the big attraction of GC is memory safety not convenience.

Try Rust. Proven memory safety, no GC.

Until one tries to do GUI programming, then it is Rc<RefCell<>> everywhere, or arrays with vector clocks for managing old entries.

no opportunity at $CURRENT_JOB, but in the future, sure, it is definitely on my radar!