Cool, I had that on my list :)
I propose to do it differently: instead of creating tags in random namespaces, I propose to put them all as class-less consts under the Symfony\Component\DependencyInjection\Loader\Configurator\tag namespace.
That way, in PHP DSL config files, ppl would just have to type tag\ to be provided with the full list of possible tags, all bundles included.

Done. Using composer file autoload, but perhaps we could just require_once the Resources/di/tags.php file from the container extensions __construct method instead, so it's only available during compilation time.
EDIT: done in third commit.

Do you like segregation by components, like introduced in the second commit ?

vs

I'm 👎. I understand the goal, but that introduces another "name" for each tag. The current are well documented everywhere. Not sure if this is worth it.

@fabpot how about following the Events model: each bundle/component that introduces a new tag needs to add a new constant into a Tags class at the root of the bundle/component.

@afurculita: FI, that was the first version of this PR: ogizanagi@7a27b6b

To empty my stash, here is what I had:

<?php

namespace Symfony\Component\DependencyInjection\Loader\Configurator\tag;

/**
 * Define aliases based on the value of container parameters.
 *
 * The required "format" attribute defines the service to alias and can use any container parameter.
 *
 * You need to manually add the AutoAliasServicePass compiler pass to the container for this feature to work.
 */
const auto_alias = 'auto_alias';

namespace Symfony\Component\DependencyInjection\Loader\Configurator\tag\container;

/**
 * Enable services implementing the ServiceSubscriberInterface to have their service locator created automatically.
 *
 * The optional "key" and "id" attributes allow setting entries to the created service locator.
 * You can repeat this tag several times to set "key"/"id" pairs on the locator.
 */
const service_subscriber = 'container.service_subscriber';

In my local stash, I also started adding docblocks on the consts, as I believe that's a great place to have some words about what behavior each tag provides. Being able to have that info directly in a click in my IDE would be another great DX improvement that this would provide.

Of course, I'll update the PR to include those if we can convince @fabpot :)

The doc blocks could also be the place where we tell about which interface adds the tag by mean of autoconfiguration (when applicable.)

Moving to 4.1.

I'm closing because this is staling and controversial for now. Let's re-open later if we want.