Dave, I am almost certain that many memory-oriented objects on the heap are re-threaded into a memory list or pool, but there are many reasons why that doesn't mean they are immediately re-used. In fact, many things returned to the heap merely stay there, idle until process exit. If you ever see a Windows error message, "Virtual Memory Exceeded" it is because your heap grew too large - in turn, because the reclamation process was not effective.
This next piece will seem like a diversion, but I have method in my madness. Those old enough to remember the USA "Orange Book" on computer security will perhaps remember that in order to reach the "C3" level of security accreditation, it was necessary for Microsoft to implement a TOTAL rewrite of Windows internals. (Thanks, Dave Cutler!) Otherwise, no Microsoft system would have qualified for further Government contracts. MS-DOS 6.2 and Win3 (and Access v2) would not have passed because their handling of memory was EXTREMELY loose.
Windows NT came out so that Microsoft could qualify for the C3 rating and sell to the US Government. Otherwise, we would all be living in a UNIX-based world. These days, "C3" and the other ratings are no longer used, there is a newer standard - and yes, Win XP complied at the time and Win10 is even higher on that compliance scale. The major "new" feature of WinNT was better use of the advanced memory management hardware that was becoming available on Intel systems, which in turn meant that hardware process isolation was now possible. This hardware isolation changed the way the O/S looked at memory.
Back to memory usage issues: There are levels of re-use. Returning a memory chunk to the heap makes it eligible to be repurposed within the same task, but the C3 "process isolation" principle stops it from being used by another task until process exit is finished. Which is why in my discussion I emphasized multiple classes of object reclamation.
Anything built on the process "User" stack gets released back to the stack at sub or function EXIT, which includes EVERY local variable in a function or sub (except those declared as "STATIC"). As part of that release, when the pointers to objects vanish, Access knows it and has "destructors" to release things related to those locally defined object variables. The actual variables go back to the stack. Remember, object variables are pointers to some other structure. Object structures created through those variables go back to the heap, where re-use is possible but not always likely.
The reason I say "re-use is less likely" is because of random object release. When the process is new, memory is smooth and empty. Once things get hot, memory allocations occur and eventually, memory releases occur. But the random nature of those releases will leave memory fragmented if you have two big chunks of released memory but have one more chunk of memory between them that is still active.
ALL objects and variables (and code and anything else you had in the process) are totally reclaimed by process EXIT. Inside of your process/task, memory is used in small chunks - piecemeal, so to speak. But Windows treats memory allocation in units of pages, where a page's size depends on the specific hardware settings, but might easily be as much as 8 KB of contiguous memory aligned on an even address boundary of 8 KB.
At EXIT time, Windows takes over the pages of released memory and adds them to the Free Page list. That list is safe because as part of the process of preparing to re-use the memory by handing it to a different task, Windows wipes it before taking it out of the FPL. If you ever wonder why task startup takes so long, sometimes it includes time required to pre-erase the memory allocated to you (based on object re-use rules).
My comments about external objects relate to the fact that an external object is part of its own process with separate memory. When Access exits, its memory gets wiped - but the memory of the external app object is still in use and can still have its own active objects. Process-separation rules say that you CAN'T touch anything directly in that other process. You have to ASK it (via application object methods) to clean itself.
To look up more about memory-page flow in Windows, look up "Windows Paging Dynamics."