On the subject of hierarchical configuration directives - you can start
looking at the behavior of back-config. It's still extremely incomplete.
If you want to see what's currently visible, add
database config
rootpw <something>
to your slapd.conf; the suffix and rootdn are hardcoded to "cn=config".

There is no write/modify support here yet. It's taking a long time just
to implement all of the read support...

Hm, this actually brings up an interesting point -- How do you handle
updating replica's vs. masters? And what about other auth mechanisms
instead of using a rootpw?

For item #1:

My master's slapd.conf is very different from the slapd.conf on the
replica's, as it has minimal indexing, and a completely different set of
ACL's. How am I supposed to make modifications to the replica's
configuration? I have to assume that the back-config DB is never a
candidate for replication? In that case, it will be a pain to make updates
to the replica's, as you'll have to modify every single one individually.
If not, then do we have multiple back-config directives, one per system,
residing on the master, so that when a modification is made to the master
for a particular replica, it'll propagate the changes to that particular
replica? Or do we now require that the master & replica always match in
configuration?

For item #2:

I don't have any rootpw defined in any of my systems, as I use SASL/GSSAPI
authentication for all write-related activity. I assume for the
back-config stuff then, it will be possible to define an ACL saying what
principal can write to that DB? Or a configuration directive?

"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin