@douglas-reid for selfish reasons, I would say no because it will make my life harder But seriously - I would say no because supporting multiple labels at the same time is going to cause problems for any client of the telemetry (not just for Kiali, but anyone trying to analyze the telemetry) - it will require multiple k8s requests to determine what pods were participating in a particular timeseries within the telemetry (because some could be labeled with app, some with app.kubernetes.io/name, some with the /instance label - then we get into the different version labels).
An alternative solution would be to have the helm charts accept optional arguments so you can define what app and version labels you will be using in your mesh. So I can say at install time, "I am not using “app” or “version” - instead I will use “app.kubernetes.io/name” and “app.kubernetes.io/version”:
helm --set telemetery.app.label.name=app.kubernetes.io/version --set telemetry.version.label.name=app.kubernetes.io/version
The helm charts that build the mixer metric definitions would use these to define the attribute expressions.
This would have the added benefit it providing a way for users to define their OWN custom labels - because you know someone is going to say, “My company uses the label “application” (or fill in the blank for whatever label name someone is going to want to use) for the app label - how can I tell Istio to use that?”