I haven't used baggage myself, but my impression is that care is needed to avoid trouble. One thing that comes to mind if adding baggage attributes to spans is unintended collisions of baggage and span attributes. This is an example where namespacing attributes can help.

As an aside, it was a deliberate design decision NOT to re-implement features specific to Honeycomb's SDK in clj-otel. These features are being put forward for inclusion in the OpenTelemetry SDK, or are dropped entirely from Honeycomb's SDK. One notable example is Honeycomb's DeterministicTraceSampler, which initially had a different hash calculation, but now has adopted the same (and much simpler) implementation found in the OpenTelemetry SDK.

Yes, it's great that you do so. If they are worthy, I suppose OTel will end up adopting them, and then we'll know it's time to wrap them. As for baggage: • I don't yet need cross-service trace propagation. • I was interested in it for thru-span-hierarchy propagation (which is not the main intended case for baggage but can be implemented with an optional propagator like honeycomb did), but I'll wait till I see a clear need for it before trying it.

You may be interested in using (meta &form) in a macro

I'm sure I looked at this some time ago, perhaps I need to revisit this

For now I put this in place. Didn't yet add extra args to augment attributes from call site.

(defn -opts-for-code [var-meta]
  {:name (str (:name var-meta))
   :attributes {(str SemanticAttributes/CODE_FUNCTION)  (str (:name var-meta))
                (str SemanticAttributes/CODE_NAMESPACE) (str (:ns   var-meta))
                (str SemanticAttributes/CODE_FILEPATH)  (:file      var-meta)
                (str SemanticAttributes/CODE_LINENO)    (:line      var-meta)}})

(defmacro opts-for-code  [f-as-var]
  `(-opts-for-code (meta ~f-as-var)))