This is likely obvious to many but I just stumbled into it. The advantage of the Lookup function is it allows you to create a calculation that references related fields and that it can be indexed. However, when used in a merge variable, it can be misleading (was to me anyway . . . doh!). As a matter of fact, it does nothing like it was meant to do. Let's say you establish variables via conditional formatting of a text object and one of those variables is called $ADDRESS, as in Let([$ADDRESS=Lookup(Contacts::Street Address)&" "& Lookup(Contacts::Address 2)]; etc. and insert this on a layout (in this case a layout that prints cheques) as <<$ADDRESS>> , every time the address changes all records will change, thereby defeating the whole notion of keeping a history of an employee's address true to each cheque over time. The solution, of course, is to create lookup fields in the relevant table to look up "Address 1, Address 2" etc. from a contacts table, which is what I had always done.
I've been eliminating countless calculation fields from tables by using Merge Variables, but getting rid of lookups is something well worth avoiding. Thumbs up for Time Machine.