As of COmanage Registry v1.0.0, it is no longer possible to change the global setting for Organizational Identity Pooling after initial setup. This capability dates back to very early Registry code (v0.2), before the introduction of audit capabilities via Registry History and Changelogs and before the introduction of Enrollment Flows and Petitions. In short, these features make it too complex to change this setting after actual use of the platform has begun.
Consider switching from the default "unpooled" state to "pooled". A given Org Identity for a given login identifier may have been created in multiple COs. Each has its own history (transactional and changelog), and each may have been created by separate petitions. When Org Identities are then pooled, how should these history records be merged? What should become of the petitions? Should they be "rewritten" as though the original identities never existed? Furthermore, what if an administrator in one CO manually added a second identifier to one of the Org Identities, and it conflicts with the record created from another CO? One approach to dealing with this mess would be to simply allow both original Org Identities to persist post-pooling (and just be made available to all COs), but that sort of defeats the purpose of pooling in the first place.
Alternately, consider switching from "pooled" back to "unpooled". If an Org Identity had been created by petition in one CO, does that petition have to copied into all other COs? Does history data need to be copied as well? What happens if an administrator wants to go "back in time" to examine the record prior to unpooling? How would that work if the Org Identity were created prior to unpooling but not added to the CO until after unpooling?
These questions can be answered, but typically the context of the specific deployment matters and as such any migration between pooling and unpooling can't be handled by just ticking a checkbox.