Thanks @KodrAus. this seems valid. do you want to contribute the PR, else I should be able to pick this up sometime next week.

I’m happy to put a PR together for this 👍 I imagine at some point you’ll be locking down those traits so they can be stabilized.

Thanks @KodrAus. Yes, we are targeting RC in Oct, so would have stable API by then,

I've opened #2129 for this.

As an aside, it was probably discussed somewhere, but I thought the API here was a little surprising. The LogRecord trait appears to mostly be setters for the LogRecord struct so am not sure why it's preferable over using the LogRecord struct itself. It seems like it could be a compatibility hazard going forwards, since you can't introduce new methods without breaking changes, a no-op or panicking default, or forcing additional trait bounds on users of the Logger trait to extend it. None of those options are really appealing in the long term. There could be some bigger plan here I'm missing though since I'm only a casual observer.

The LogRecord trait appears to mostly be setters for the LogRecord struct so am not sure why it's preferable over using the LogRecord struct itself.

The OpenTelemetry API is intentionally minimal, leaving implementation details to the SDK. This gives users the flexibility to bring their own SDKs without being forced into specific design choices. For example, with LogRecord, someone might want to use their own data structure for storing attributes. Or the SDK may want to directly convert the record data in export format without storing it in intermediate ‘LogRecord’ structure. If those details were baked into the API, it would limit their options. By keeping the API simple, we avoid locking users into specific implementations and allow SDKs to handle the details in a way that best suits them.