> Tables, functions, threads, and (full) userdata values are objects: variables do not actually contain these values, only references to them. Assignment, parameter passing, and function returns always manipulate references to such values; these operations do not imply any kind of copy.
I also seen this described as "reference semantics" and "value/copy semantics", maybe that would be a better term?
When we use exactly “pass[ing] [an argument] by reference” it usually means passing an argument by a reference to its location (opposed to contents). I think we just avoid using that exact form if we want different meaning, there’s no proper form. Cause applying it to values rather than arguments rarely makes sense. Copy semantics are non-trivial in general. Shallow copying may not be sufficient to create a proper copy and deep copying may copy half of the vm state, think f(_G, debug.getregistry()).
The Lua manual probably had the same issue with wording it.
Again, C++ with copy constructors is an exception here. You usually receive a copy (shallow or deep depends on a constructor) if no reference, pointer or move semantics given. That was the edit-removed part above.