The current implementation of the toBuilder() method on an instance of the OpenTelemetry class is dangerous. It copies the TracerProvider and the MeterProvider to the new instance that is being built. This will mean that all of the current state of those two instances will now be shared across two instances. I think this will lead to unexpected behavior. For example, one of the instances could be shut down, but the other not, but the underlying TracerProvider would be shared, and hence both would effectively be shut down.
If we are to provide a way to "clone" an existing instance of OpenTelemetry, we need to make sure that none of the state is shared between the resulting instances, so they can be used independently.
@jkwatson One of the ideas for having multiple OpenTelemetry was indeed to share state though - same everything except for remote propagators because those can be different for different backends. But the shutdown aspect is definitely tricky need to think on this.
The Resource instance is also a case to be considered. Should it be shared between two? allowed to be different? If different, how does that impact SpanProcessors that are utilizing the Resource when the SDK instance is cloned?
It seems like there are many ways to possibly implement this, and many of them will probably end up being surprising to an end-user in one way or another.
We had an extensive discussion of this issue at the special topics SIG meeting this week. Decision for now is to remove the toBuilder() methods and require building an instance from scratch if you want a separate instance, so there is no danger of unexpected shared state across instances.
Once that is done, we'll revisit making it easy to "clone" instances of OpenTelemetry, and continue iterating on the SDK configuration story.