Retaining the : is an intentional design choice, I think there is value in not altering keywords, particularly when considering that span names may be queried in the telemetry backend. Remember you are free to use a string or a symbol instead of a keyword for the span name:

(defn square [n]
  (span/with-span! 'my-app/squaring
    (* n n)))

yep, that makes sense. just trying to enable my span naming laziness. 🙂

I will bear this in mind though. I've been thinking about adding a feature to enable span-opts to be modified by an arbitrary function for all spans as they are created. This could be used for tweaking span names, for example. The use case I have in mind is copying specified key-value pairs in baggage to span attributes. I know Honeycomb has a basic form of this idea in BaggageSpanProcessor class in their Java OpenTelemetry SDK.