In order to view both Server and Client perspectives, on the Play dropdown, set the Number of Clients field to 2.
Example 2.2 failed because the replicated Multicast function did not handle preserving the state of the chest past the time it was executed. In that case, a natural solution might be to try to use a replicated variable to solve this problem instead.
In this example, a RepNotify boolean is used to save whether the chest is open or not. Again, stand the client out of the blue ring and have the server activate the chest. What happens when the client walks into the right afterwards? The client sees the chest open, but also sees the gold effects play, even though that happened awhile ago on the server!
When the chest becomes relevant to the client again, the client gets the change to the replicated variable and the corresponding RepNotify function is called. Unfortunately, the client has no way of knowing that the variable actually changed well in the past, only that it did change, which is insufficient to handle this particular case.
Blueprint Breakdown
In the BP_Relevancy_Replication_RepNotify Blueprint's Event Graph, as seen in the commented section below, the OnChestTouch is overriden to set a RepNotify variable who's OnRep function is responsible for handling the visuals of the chest opening.
Below is the OnRep function called when the variable bChestOpened is updated.
Click for full view
While this does allow the client to get the updated value when the chest becomes relevant, it also means that the client will play the gold particle effect, even if it should have finished long ago on the server which is also undesireable.