but doesn't it kill any memory that is still hanging around but not in use as well?
By the fact that you need exclusive rights on the DB being compacted, all RAM has already been released. None is hanging around. There is a moment before you start a C&R according to preferred methods such that the DB file is closed and has
no component in memory. That is what I mean by "no RAM is hanging around."
In Windows, when you have a process with its own stack and heap management (and Access falls into that category), they can bollix up memory as they will. Windows doesn't care because it gave the process that memory precisely for its own use.
Once you talk about gaining exclusive access to the DB, you often have to close and re-open Access, selecting the option for exclusive access, in order to do this properly. OK, it is POSSIBLE to do this without closing first. However, normally you would close the file and open it in exclusive mode.
In so doing, your non-exclusive process runs through what is called "process rundown" which ends when Windows reclaims ALL memory (program, data, stack, heap, and miscellaneous loose stuff) that had been part of the process hosting the MSACCESS.EXE image. Anything that HAD been part of the Access infrastructure has been dissolved and wiped clean. (There are exceptions having to do with shared image sections but they don't invalidate the argument.) The reclaimed memory from a process run-down goes to the Free Page list because the Exit forces a write-back and flush of any pending "dirty" buffers before the rundown can complete.
As to the second part of your question: Yes, part of the problem is pointers. You can't release the memory because you cannot assure there are no pointers to it unless you do a full-blown C&R, which does what it does in the order that it names. The first thing is compaction. That is when unused (obsolete) items in the DB file are identified by "deleted" flags for each one. Access simply copies what ISN'T deleted into a new file. Then it closes the old file, deletes it, and renames the new file to match the name used by the old version.
The second thing is trickier - repair, which means that Access has to visit every internal structure to verify the pointers are consistent. Access is all about pointers. That is why even manual GC is such a pain and why it takes a while. It is only possible because the structures used in Access contain "markers" that help Access validate what it sees. What I know about this has been gleaned from a few articles over the years and I don't know if I still have the links. But the idea is that each memory structure has a fixed-structure header followed by a sub-structure dependent on what type of structure it represents. No, I don't have details on that. MS doesn't publish Access internals. (Darn it.)