A list is not a mutable structure. When evaluation of a list entails a change in the evaluated value of an entry then a copy is made (and the address changes).
A Vector (or Matrix, Array, ie. rtable) is a mutable structure. In order for in-place semantics to work for rtables via procedure calls they are not copied under eval. Thus a procedure receives the very same rtable, when it is passed in as argument to the procedure call and evaluated up front. And so the desire for in-place semantics is one reason that rtables are not copied under eval.
Another reason is efficiency: the term "rtable" stands for "rectangular table", where hardware numeric entries (or the references to symbolic DAG entries) are stored contiguously in memory. It's a great benefit that passing the data of a float rtable to an external routine only needs to pass the reference to its beginning. Full copying under normal evaluation rules for procedure calls would be a performance damper.
The functionality to force an evaluation throughout all entries of an rtable is provided by the rtable_eval command. Below you can see that command producing a copy.
note: When doing such examinations it can sometimes be useful to utilize lprint and eval(...,1), so as not to be misled by evaluation occuring only during printing.
Access to individual rtable entries, via indexing, does entail full evaluation. This is natural, for programmatic purpose.
While assignment to an entry of a list "works" (up to the 100th entry, by default), it is not true in-place semantics. The underlying list is actually replaced by a full copy whenever this occurs. This is thus a very inefficient programming practice, and should be avoided.
Here's a little more related to list evaluation,