I'll try to answer all points in this mail:
slapo-rwm goes in the right direction, because you can condition events
based on stored knowledge of previous events; however slapo-rwm is not
the solution to your problem right out of the box, because attribute
mapping and DN rewriting are entirely decoupled, so you cannot use the
knowledge of the bindDN to alter attribute mapping. I guess you should
rather use a custom solution, inspired by slapo-rwm, that does some
pattern->action (regex?) in rewriting attributes. Or, since it is not
exactly clear how DN info should influence attribute mapping, you may
perhaps solve your riddle by having different users treated by different
virtual databases, each based on back-relay^* and with a different
mapping pattern, all pointing to the same real database.
*^I write back-relay under the assumption that the real database and the
virtual databases are in the same slapd instance; if they are not, then
use back-ldap instead.
If you want to play with DN rewriting/attribute mapping with 2.2 you
don't actually need the slapo-rwm because in 2.2 it i embedded in
back-ldap and back-meta (in 2.3 it's still embedded in back-meta but it
has been decoupled from back-ldap into an overlay to be usable with other
backends, significantly back-relay; I've figured out a way to reuse it
for back-meta as well...).
To answer Quanah's question, I think your ITS, as answered by Kurt, is
now entirely fulfilled by 2.3 code, by using back-relay and slapo-rwm;
the only thing it doesn't allow is to use the requested name instead of
the canonical one, e.g. returning "userid" instead of "uid" when "userid"
is requested (this was a long debated question; I see the issue and I
agree with the common answer that the current behavior is preferable; for
those that still wish this to be possible, the answer is that it cannot
be done with an overlay, so there's very little chance that it will ever
be possible with OpenLDAP, except by hacking the code).