throwing all dynamic changes into a single cn=subschema subentry (or
99user.ldif as some other servers do) is messy. I prefer to keep things well
organized, with related schema elements all in their own entry. This makes
schema development and management a lot easier and understandable,
particularly when you're wondering what schema element came from where.
There are other ways one could specify which internal schema entry/tree
to use when that is not specified in the LDAP update operation -
e.g. cn=schema,cn=config& children could hold mappings from OID/schema
element name to the entry which should receive the update. Not sure if
that's any better. I wonder what X.500 servers do.