--enable-feature=promql-delayed-name-removal has remained a feature flag for v3. It's technically a breaking change, so the next chance to make it the default behavior will only happen with the v4 release.

This issue intends to track what's needed to make that happen.

First of all, it would be good to learn about experiences users have made with the flag.

I think the queries that change the behavior are all easy to fix and are more or less nonsensical edge cases to begin with.

The most problematic concern is IMHO the inability to easily dissect a query and run parts of it with the same result. To explain that in a bit more detail, have a look at this query:

count(count_over_time({__name__!=""}[1m]) > 10)

It tells us how many series have more than 10 samples over the last 1m and works fine with promql-delayed-name-removal set. However, if you want to dissect the query and just run count_over_time({__name__!=""}[1m]) > 10 or count_over_time({__name__!=""}[1m]), you will get the vector cannot contain metrics with the same labelset error even with promql-delayed-name-removal set, because this error triggers when Prometheus returns the result to the outside and then removes the metric name, creating the collision. (With the whole query, the removal only happens after count has removed the ambiguity.)

This is in particular a problem for PromLens, because it performs these query dissections under the hood.

UPDATE: Adding another item to take into account up here so that it does not get lost in the discussion below: How to handle a case where we aggregate (by name) a number of series with the same name where some of the names are marked as to be dropped and others are not. The aggregation will create series where the name is both marked as to be dropped and not. See #17161 for a deeper discussion (and the preliminary solution – however, we have to pick a permanent solution before we declare the feature stable.)