While we're at it, we should add a consumer option for specifying additional locations in which to store contextCSNs. This would e.g. solve ITS#4626 by allowing a consumer in a glued subordinate to keep its parent context up to date.

One thing we've been kicking around lately was a dream-list feature of "throw a contextcsn on any arbitrary entry." Our motivating problem was essentially

+ dc=syncproved,dc=rutgers,dc=edu + ou=Boot-Time Configuration + ou=Dynamic Configuration

We wanted the ability to arbitrarily add a contextcsn attribute into "ou=Boot-Time Configuration,dc=syncproved,dc=rutgers,dc=edu" despite the fact that the suffix/syncprov was on "dc=syncproved,dc=rutgers,dc=edu". This would be combined with, essentially,

/* if bootconfig is fresher than we are, reboot to get it */ if (contextcsn(BootConfig) > (``date`-/proc/uptime`)) restart;

to get things that can only be configured at boot time.

(No, we're not actualy that crazy with our systems, it's just a daemon; but you get the idea.)

In the end, we're just searching for entryCSN>=lastRestart with base of ou=Boot-Time. But contextCSN seems more eloquent (only pick up one entry) and this might be (roughly) in line with what you were considering, or give you some ideas (ridiculous though they might be).