add complex value alternative

Signed-off-by: David Ashpole <[email protected]>

proposals/2024-09-25_metadata-labels.md

@@ -54,7 +54,7 @@ For example:
 
 When a query for a metric returns multiple metrics with a different `__type__` or `__unit__` label, but the same `__name__`, users see a warning in the UI.
 
-Users don't see the `__type__` or `__unit__` labels in the Prometheus UI next to other labels, but the unit displayed next to the value.
+Users don't see the `__type__` or `__unit__` labels in the Prometheus UI next to other labels by default.
 
 Users see no difference to exposition formats.
 
@@ -114,6 +114,15 @@ This solution is not chosen because:
 * Users might be surprised by, or dislike the additional suffixes and delimiters in the metric name results
   * Mitigation: Opt-in for query engines?
 
+### Type and Unit in complex value types
+
+Unlike other metric types, native histograms are a complex type and contain many fields in a single value. The metric type and unit could be added as fields of a complex value type in a similar way.
+
+This solution is not chosen because:
+
+* Requires intrusive changes to all formats (text, proto, etc.).
+* Requires new PromQL syntax for querying the type and unit.
+
 ### "Hide" __type__ and __unit__ labels in PromQL, instead of UI
 
 Existing UIs don't handle the `__type__` and `__unit__` labels. To mitigate this, PromQL could omit the `__type__` and `__unit__` labels from the query response. Doing this would avoid requiring UIs to update to handle the new labels.