Just as we have agents for "before new mail arrives" and "after new mail arrives," we should have agents for "before replication begins" and "after replication completes." These should be executable by both client and servers. (Note: they could also be just database-level events, similar to PostOpen -- but the agent trigger seems easier to accomplish.)
Such processes should be able to access replication stats (updates, deletions, bytes, seconds, etc) as well as STOP replication in the "before" case.
Some examples of where this would help...
1) Prevention of replication of very old replicas polluting production with prior deleted documents.
2) Rebuild of key indicies after a replication cycle.
3) Auto-notification of stats for replicating clients.
4) Deletion tracking (take a snapshot of docs in a folder pre-replication. Examine folder post-replication.)
5) Distributed sequential number resolution.
But mostly we need this kind of capability because development services that monitor data distribution are simply non-existent. If we can't get something like TriggerHappy directly integrated into the product, having a service like this would address SOME of the problems with distributed applications.
There may have been a time when performance impact was a concern for this idea, but with multiple REPLICA threads on servers, and background agents available on clients, there's really no reason not to make this available.