roriscrave
FYI, the code you showed at the start of the thread is actually the classic example for explaining references.
Unfortunately most discussions on the web about this are full of complete rubbish, so it's quite hard to get good information quickly. In particular, never pay attention to any discussion of "pass by value vs pass by reference" that takes more than 5 posts
There's an easy way to treat this though:
Considered as data, references act like "primitives" (what the LUA article on wikipedia calls "atomic data structures") If you execute refA = refB, then refA gets the same value as refB. It does not get a copy of the value(s) of the table (object in OO languages) that refB references.
Your example demonstrates this perfectly.
This bit is based on Java, but AFAIK it's also true for LUA:
In Java, you can put references to objects into an object (and you do this a
lot). In that case, making a new object using the approach suggested by Nekiro's above would copy the references in the outer object rather than make a copy of the "inner objects" referred to by fields in the outer object. (BTW Nekiro's approach is 100% correct for your example)
This distinction isn't usually noticeable to a developer, but occasionally it matters. Funnily enough a case where it's visible turned up in the "tree cutting" example I'll share with you soon, so you can see a live example later.
(BTW I didn't check Switch's example above, but it looks promising. The usual terminology for copying an entire table/object, including inner tables/objects is "deep copy" or "clone", both of which are used in Switch's post.)