Description
Spec should allow to mutate multiple tracestate entries in a single mutation. Here are scenarios that might be enabled:
1. Share base SDK
Single base SDK that has it's logic of updating tracestate key may need an extensibility model for special type applications with additional tracestate key required.
Application Insights is designed for high-tenant apps. SDK today requires to propagate an app-id between components which allows to build a full trace efficiently. By knowing app-id of a caller backend knows which telemetry store to query for data.
There are also internal applications using hierarchical identifiers to address spans. Hierarchical identifiers will not necessarily be implemented in Application Insights SDK. Also not every component is an internal app and it may not support hierarchical identifier.
That's said internal applications will need two keys in tracestate. One that is set and maintained by base SDK and containing app-id. It will enable high-tenancy. Second - for hierarchical identifier and additional scenarios it brings.
One alternative here is to host smaller tracestate inside one of tracestate's key. This smaller tracestate will also need key/value store and values will point to specific span-id to know who was the parent in it's own trace graph. However this makes field value look worth without benefit.
2. Share trace properties
It is beneficial for many scenarios to share some common trace characteristics like sampling score. See this #8 (comment).
Sharing a key in tracestate allows to enable even more vendors collaboration scenarios. Alternative for this is parsing each-other headers.
Drawback of documenting trace properties is a risk that tracestate will be used as a baggage.