IMHO, the most appealing feature of ACIs is the fact that in principle access rules get replicated along with data. However, the lack of a standard defeats this purpose when getting to cross-implementation replication, migration and so. Moreover, one might want to have different access rules for different shadows of the same database.
This probably breaks one of ACI principles - that an acl is stored "with the entry itself", as shadow probably means "the same entry shadowed", rather than "shadowed copy of an entry"(?). On the other hand, if ACI would have been designed with object-like manner, some attribute could keep a piece of information about a particular "shadow" it's effective with.
Currently I have a few openldapservers with common entries, and in some cases I replicate only needed branches, anyway, in some other, I rather prefer to add some (multi or single value) attribute like "thisEntryUsedByHost", replicate the whole tree, and on the application which uses particular replica, add some filter in &(thisEntryUsedByHost=my.current.host.name). I don't have any comparable source of information, is something wrong with such usage?
Finally, right now access control on OpenLDAP's slapd can be modified without the need to stop and restart it, by means of cn=config; there is work in progress to allow configuration replication. As such, OpenLDAP offers better means to achieve the same purpose without ACIs, with the access determinism guaranteed by avoiding the use of ACIs.
That's ok, I just started using cn=config lately and I'm not familiar with it, however, isn't there other side of penny - one can modify config information without restarting, but modified information is not stored/saved between restarts ? ACI is somehow "static", although it's not "static" in common sense :)
Regards, Piotr