When we wrote the RFC, we decided not to support properties (aka metadata) yet since OpenTelemetry themeselves have not fully adopted it. For example, the metadata parameter in the Set API is optional in the spec. Some implementations of the OpenTelemetry API support properties, but others don't. See open-telemetry/opentelemetry-specification#3972 (comment).

We should've been more clear about this in our RFC. If we are not going to support properties yet, we should probably ignoring them (not extract them). If we ignore them, for a baggage header like this:

baggage: key1=value1;property1;property2, key2 = value2, key3=value3; propertyKey=propertyValue

We should extract:

key1=value1
key2=value2
key3=value3

Related: in .NET we are not ignoring properties (yet?), so we end up (accidentally) extracting them as part of the value instead of separately:

key1=value1;property1;property2
key2=value2
key3=value3; propertyKey=propertyValue

This will be problematic because when we inject those values back into a baggage header, we will end up encoding the semi-colons:

baggage: key1=value1%3Bproperty1%3Bproperty2,key2=value2,key3=value3%3BpropertyKey=propertyValue

This will result in the properties being part of the values for any other downstream service instead of being separate metadata, which is... not great.