Slurpd and syncrepl really took opposite approaches to replication. While syncrepl allows consumers to be configured without any special configuration of the provider, slurpd allowed slaves to be configured without any special knowledge. This feature allowed slurpd to be used to replicate to pretty much anything that understood some flavor of LDAP.
With syncrepl, the consumer must minimally understand entryCSNs, entryUUIDs, and a contextCSN. This requirement would appear to limit our reach. But with delta-syncrepl, we actually need nothing more than a contextCSN to keep track of where we are in the changelog. And when using delta-syncrepl thru an LDAP proxy, there's actually no requirement that we store the contextCSN on the remote server.
We could simply store the contextCSN as a DB-specific attribute of the proxy DB's entry under cn=config. Whether we do this by explicitly modifying the syncrepl code, or by using an overlay to accomplish the sleight-of-hand doesn't seem to matter much. (Though there may be more uses for a customizing/mapping overlay here; e.g. translating LDAPv3 schema to MS AD.)
Just wanted to mention this here before I forgot it again.