The problem is that programmers don’t always do that, either because they are not that experienced or they are in a hurry.

The real danger is when code is long lived and worked on by multiple people. One bad commit after a late night hacking session and now there is a zero day just waiting to be discovered.

Safe languages don’t rule that out but they make it profoundly less likely.

Also, the DEBUG_NEW thing is useless in practice since, from memory, it stops you using placement new, and dependencies typically don't participate, so a zillion unlabeled leaks is the usual result from the common case of you failing to call some dependency's free function.

And the allocation IDs (and therefore _CrtSetBreakAlloc) are pretty worthless in practice for multithreaded programs, because the allocation order isn't deterministic.

I use the LEAK_CHECK_DF flag in the programs I write (and the CHECK_ALWAYS_DF is worth investigating too), but the only point is to indicate whether there are leaks on exit, yes/no. If no, great; if yes, well that's useful information, but the actual output is almost never helpful. (Though occasionally I do somehow introduce a leak from something that happens before the first thread is created.)

Well, unless they are doing something incredibly stupid including stepping over several explicit warnings of "don't do this unless you are very sure about what you are doing".

I think c++ should keep the good modern things and fork (restart) from there by breaking backwards compatibility, c++23 will be frozen with some fixes.