Correct me if I'm wrong, Zac, but using a calculation for "if box checked, use Address A" would lead to problems if you tried free typing when the box isn't checked. Because if the "else" condition is an empty string, then various edits you could make would actually wipe out/override anything typed into the client B fields (at least, that was the behavior last time I tested it, but it's been a few years).

To overcome that, I think you would need 3 address fields. If the checkbox is unchecked, show the existing Client B. If it is checked, show a Client C field (which could be labeled as Client B but would be a separate field/variable). Then client C could be read-only and have formulas for "if checked use client A value, else use client B value". That way C would have values in either case and could be used behind the scenes if pushing this data into another system.

You are correct, if you ever go back to edit Client A address with the checkbox unchecked it would wipe Client B. 

Having three fields is a worthwhile workaround if the user requires physically seeing the two different address fields are the same. Most times I've used this option I just don't display the second set of address fields and use client A in my integrations/workflow when the use same checkbox is checked.

In which case I would move the checkbox between client A and B's addresses and hide the fields when the option is checked.