I see where the question is coming from, definitely. But actually a(1).n can be referenced. Replace the first msgbox(r.n) with msgbox(a(1).n) and the code works as expected.
For another example, return to msgbox(r.n) but change the preceding line from r = a(1) to r.n = a(1).n. This also works as expected.
The problem rather seems to be assigning from a(1) to r. Since we don’t have VarPtr (a la VBA), it’s tricky to see more of what is going on, but I definitely can replicate the behavior with Calc 6.4.2.2.
You would imagine that the object reference stored in a(1) would just be passed to r with the assignment r = a(1). I checked to see if Newing r had any effect, but you can Dim r as Object or even Variant with the same results.
Dimming r as Object does show, however, that something is happening with r = a(1). If you Dim r as Object you can still run the code and get the 0-valued message box. Now, if you Rem out the r = a(1) you, of course, get an error since BASIC knows of no n member for the generic object r. So it is like you are in copy semantics and setting r to the class but getting a new variable table, i.e., no cloning.
Have you tried properties in the CTest2 class?