I've encountered one minor oddity. Prior to the upgrade, I had some
clients which I had configured to use extensible matching equality
filters against dn components in order to traverse multiple branches
of our DIT in a single search while avoiding other branches. For
example, given the following simplified DIT structure:

Since the upgrade, the above filter returns entries with matching
uid attributes from all three branches. In addition, this filter:

(&(uid=ktrustin)(ou:dn:=Branch1))

matches nothing at all even though there is an entry with a matching
uid and dn ou component in that branch.

Other bread crumbs:

* Extensible matching filters using the few other dn components
we employ here (uid, cn) seem to work OK, so my problem may be
isolated to the 'ou' attribute.

* On comparing core.schema from old and new OL versions, I saw that
the 'ou' attribute is SUP 'name', but that the 'name' attribute
was commented out in OL 2.2.23's core.schema (perhaps because it
is now defined in the source code?). Thinking that this change
might be somehow related to my problem, I tested another SUP
'name' attribute (cn) in an extensible match filter against a
dn component, but, as mentioned above, using 'cn' did not
reproduce the problem.

* After reviewing rfc2254 and draft-ietf-ldapbis-filter-xx,
I also tried specifying the matching rule in the filter, e.g.:
(&(uid=ktrustin)(!(ou:dn:2.5.13.2:=Branch3)))
but (as expected) had the same undesirable results.

I've worked around the change by rewriting the clients to do
multiple searches, one on each desired branch, instead of using
extensible matching to traverse several branches at once. But I'm
curious whether others among you have encountered anything similar.