Me and @Seldaek are wondering about the use case for having two tags. Could anyone share their's?

@nicolas-grekas this can happen through auto configuration - and also when you need to add autowiring hints for service subscribers. Example:

services:
    _defaults:
        autoconfigure: true

    App\Test:
        tags:
            - { name: container.service_subscriber, id: App\Foobar }

namespace App;

use App\Foobar;
use Symfony\Contracts\Service\ServiceSubscriberInterface;

class Test implements ServiceSubscriberInterface
{
    public static function getSubscribedServices(): array
    {
        return [Foobar::class => Foobar::class];
    }
}

Information for Service "App\Test"
==================================

 ---------------- --------------------------------------------------------------
  Option           Value
 ---------------- --------------------------------------------------------------
  Service ID       App\Test
  Class            App\Test
  Tags             container.service_subscriber (id: App\Foobar)
                   container.service_subscriber
  Public           no
  Synthetic        no
  Lazy             no
  Shared           yes
  Abstract         no
  Autowired        no
  Autoconfigured   yes
 ---------------- --------------------------------------------------------------

i.e.: when autoconfiguration is enabled, Symfony will automatically add an (empty!) container.service_subscriber tag to any service implementing the ServiceSubscriberInterface. However, in ambiguous cases you will need additional autowiring hints so that Symfony knows which service to inject in the container of the service subscriber and thus you manually add the container.service_subscriber tag with the appropriate service ID. You will also need to add the container.service_subscriber multiple times for each autowiring hint.

In my case it's basically a BC layer. Even though the Symfony app itself uses the FQCNs, there are still samo old services (written in languages such as GO) that use the old naming convention & communicate with the Symfony app through a message queue. The idea is to standardize this over time.

@fritzmg your use case makes sense, and that kinda matches the issue I had in #48019 - except in that case the double tag actually caused problems for me.

I can totally see that you do want the most specific tags to be added, i.e. in this example you want container.service_subscriber (id: App\Foobar) to be kept, but the simple container.service_subscriber is useless I assume?

So IMO @nicolas-grekas's fix would be fine as long as it ensures the most meaningful tag is kept. i.e. do not auto-configure an empty tag (from an interface or even an attribute?) if there is already a tag present which has meaningful data, but if there is already an autoconfigured tag present with no data then it should be overwritten.

But that solely depends on the service tag, does it not? I did not do a deeper dive whether the non-specific container.service_subscriber can be omitted if there is a more specific one for example. And besides, certain services will always need to be tagged with multiple tags of the name - but different properties.

Yeah if you have multiple with different properties that's fine and the use case makes sense. I just don't see a use case where autoconfiguring a second empty tag makes sense.

Especially with the interface it's quite surprising as it's implicit and might even be a BC break situation if you upgrade and a class becomes autoconfigured suddenly due to a new feature.

i.e. in this example you want container.service_subscriber (id: App\Foobar) to be kept, but the simple container.service_subscriber is useless I assume?

The simple container.service_subscriber is not useless, it has a different meaning than the one with an id. See

Ok I see. Then I guess it's probably not fixable as too much depend on this behavior, no matter how sound it was to begin with.

We could deprecate the empty service_subscriber tag and instruct developers to use something like
{ name: container.service_subscriber, autowire: true } instead. But I have no idea if or how many other tags could be affected by this too.

Same applies to controller.service_arguments which needs to be either empty - or you need to set at least action, argument and id.