errmm... back to this thoroughly hijacked thread...
I was doing some other stuff for a while, but I haven't forgotten about this...
I made a tool to parse the memory structure of these objects and I can show a map of what is going on in your Mod02_objRange module...
When you measure these structures, you need to make sure you take a snap shot of everything at the same time, otherwise they will get out of phase as the stack moves around. For example, if you read VarPtr in your Test_rng routine and then do the MemRead in PointerToSomething, it will be wrong because the location of the variable has popped further up the stack after the call.
But, if you take a snap shot of everything, then, even if they start from different addresses, they will resolve back to the object.
The second complication you get when you call a routine to do the measurements, is that new variables are created along the way, extending the chain of pointers back to the object. And if this is not confusing enough, some of the scalar references are wrapped into "Variant References". You can read about these in your
Byte Comb site...
If you are dealing with objects (Range objects for example) and you see 00000009 or 00004009 at the location pointed to by VarPtr(object), then it is the first frame of a 4 word variant structure and the actual value (if its a pointer) is in the 3rd word of the structure, so you have to add 8 (4 bytes) to your VarPtr(obj) value to find the actual contents.
And even more confusing, the 4 flags it as a "By Ref Variant", meaning that the 3rd word points to a pointer to the actual value.
You can follow this in the attached snap shot. The top half is the results of my tool, and the bottom half is the readings that you would get from your PointerToSomething. The starting point of the pointer chains is different because they are floating up and down the stack, but, after you unravel these complexities, they always resolve back to the same object.
Although its useful for investigating the memory structure, the range object is not a useful example for checking garbage collection since no object structures are created... there are only references to global Range Objects which are not part of VBA's garbage collection. When I get time I'll continue on with this tool to use it on relevant examples.
But anyway, you said the Range objects were acting strange so maybe this will clear that up...