Jack Berg

> It MUST be treated as an opaque string from the API and SDK. That seemingly contradicts another part of the specification, which says the unit must be an ascii...

> A better approach would allow one to write gauge values synchronously with a proper timestamp I've been assuming that the timestamps reported for synchronous gauges would be the time...

Each asynchronous instrument already requires support for an `unregister()` method. See [asynchronous counter](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/api.md#asynchronous-counter-operations), for example.

@open-telemetry/specs-logs-approvers please take a look!

Pinging @open-telemetry/specs-logs-approvers. Please take a look! Otel java has already implemented and published this change [here](https://github.com/open-telemetry/opentelemetry-java/pull/4643).

> Do you think that is feasible? We'd have to maintain a table of origin units, target units, and conversion functions. Could probably have a smallish library of common situations...

It's not clear to me how exponential histograms would be converted to prometheus in general. Are exponential histograms allowed to be exported via prometheus? If yes, would the exponential bucket...

@wallezhang `GlobalOpenTelemetry` doesn't have accessors for `SdkLogEmitterProvider` because `GlobalOpenTelemetry` is part of the API package, and there is no otel logging API. `SdkLogEmitterProvider` is part of the logging SDK.

FYI, I'm working on putting together a proposal for this.

Was thinking more about whether it would be appropriate to change `process.runtime.jvm.memory.init` to something like `process.runtime.jvm.memory.lower_limit`. I believe we should not because the init memory isn't actually the lower limit....