as you know, though, there is a connection between this kind of security and garbage collection. specifically, if you're using a language that bounds-checks all array accesses, so array overruns are impossible, but relies on that same application programmer to free pointers manually, you can have a use-after-free bug, where a function pointer is written into heap space previously occupied by an array (or other data structure) to which a pointer still exists. if the attacker can cause writes to happen via that pointer, they can still break your security

garbage collection is a perfect guarantee against use-after-free bugs, unless of course the garbage collector is buggy. it's not the only possible solution; alternative solutions include statically allocating everything (abjuring dynamic allocation completely, like cobol), linear typing, never deallocating anything, and mlkit's region-based memory allocation are some alternatives which have been used. garbage collection is the most popular and probably the most practical

so it's not just that we have thousands of applications use the same debugged low-level buffer manipulation routines. it's also that we have thousands of applications use the same debugged garbage collector

i want to point out that even without having code and data in the same memory space, there are a variety of things an attacker may be able to do. when non-executable stacks, aslr, and w^x protections started being implemented, attackers started returning into libc; function pointers that point into the middle of libc would work just as well. (return-oriented programming might be more difficult, unless the thing being used-after-freeing was a large stack-allocated variable, which would be unusual.) and of course if there are shell commands, sql commands, java bytecode, or the like in data memory, overwriting them with malicious data may be just as good as uploading malicious machine code