I realized that we actually have the same problem for all the classes that extend the ShardingDDLCoordinator.
Many of the classes that extend the ShardingDDLCoordinator  parse their coordinator document at construction time. On the other hand our parsing implementation doesn't take ownership of nested BSONObj if they are not defined as object_owned, so if the coordinator document contains any nested object that is not owned, the parsed coordinator doc stored as a member of the coordinator instance will point to invalid memory.
I find this very error prone, so I was thinking to store a serialized copy of the raw coordinator document in the ShardingDDLCoordinator parent class so that we can ensure that the memory associated with all the fields in the parsed coordinator document will remain alive until the coordinator instance is destructed.