The ServerEntry stores the DN of the entry. I think this is good for better code organization. However, storing the entry together with it's DN into the master table is a very bad idea. The DN should instead be managed in the NDN and DN indices.
The reason why I'm suggesting this is because modifyDN operations will be extremely cumbersome when performed on a DN with many children. It will require each child and the target entry to be retreived and written to disk to-from the master just to change it's DN. Plus we still have the updn and ndn indices which also get updated so this is wasteful and causes a lot of unnecessary access operations. Also note that we can store a lot more DNs in a cached JDBM page then we can entries. So this will produce more memory consumption along with cache turn over.
If the modifyDN operation changes the RDN of the target, a master table access is unavoidable because the target's RDN attribute in the entry must change. However the children of the target can avoid a master table read-write operation since their RDN attributes do not change. This is again only avoidable if we do not store the DN in the master. Ideally you just want to update the indices when entries are moved around.
I've been against this drive to push the DN into the master table combinded with the entry from day one along with the drive to remove the NDN and UPDN indices. The obvious reason is due to these issues. I just did not have the time to clarify exactly why until I started looking into this bug which was recently introduced:
As I reviewed the code it was clear what this will cost much more on all the flavors of ModifyDN operations. Just imagine a ModifyDN to rename ou=People to ou=Users if it contains 100M users in it. I'd recommend we agree to fix this as recommended then I can push a JIRA on it so this can be fixed in the future (but before 2.0 since the correction will cause db incompatibilities).
Microsoft gives you Windows, Linux gives you the whole house ...