add future extension to handle type and unit in promql operations

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

Author: dashpole

Diff for: proposals/2024-09-25_metadata-labels.md

@@ -64,7 +64,7 @@ Users see no difference to exposition formats.
 
 When a query for a metric returns multiple metrics with a different `__type__` or `__unit__` label, but the same `__name__`, an info annotation will be returned with the PromQL response, which is otherwise unmodified.
 
-Aggregations and label matches ignore `__unit__` and `__type__` and any operation would remove the `__unit__` and `__type__` label (with the exception of label_replace).
+Aggregations and label matches ignore `__unit__` and `__type__` and any operation removes the `__unit__` and `__type__` label (with the exception of `label_replace`).
 
 ### Prometheus UI Changes
 
@@ -147,6 +147,10 @@ The `_count` series of histograms and summaries could omit the `__unit__` label
 
 ## Potential Future Extensions
 
+### Handle __type__ and __unit__ in PromQL operations
+
+Initially, aggregations and label matches will ignore `__unit__` and `__type__` and all PromQL operations remove the `__unit__` and `__type__` label (with the exception of `label_replace`). Over time, we can update each function to keep these labels by implementing the appropriate logic.  For example, adding two gauges together should yeild a gauge.
+
 ### __type__ and __unit__ from client libraries
 
 One obvious extension of this proposal would be for Prometheus clients to start sending `__type__` and `__unit__` labels with the exposition format. This would: