Yes, I wanted to discuss this with you. Based on this section from the spec, it seems like storing the configuration object per Meter and only updating when the configurator changes is the most natural

This function is called when a Meter is first created, and for each outstanding Meter when a MeterProvider’s MeterConfigurator is updated (if updating is supported). Therefore, it is important that it returns quickly.

However, the primary reason I deviated from your approach is because the performance implications are much greater with metrics, given that the frequency of calls to metric instruments can in many cases be an order of magnitude greater than the number of calls to create a Span via a Tracer.

Is there a reason you decided to alter your approach to the one in the current implementation for the tracer configurator? The spec doesn't explicitly mention it, but I would expect that each configurator should be idempotent.

My reasoning is that this approach will in the end be much more efficient/maintainable, you only pay the update cost on initialization and when you update the configurator (which should be extremely rare). Also, I presume the configurator functionality will be extended at some point, so it is likely that the number of places each configuration is referenced will continue to grow, which could potentially become an issue with an "on-the-fly" method.