With service locator anti-pattern being deprecated long ago, we can now use ServiceLocator class for tagged services. If you check compiler passes, it is only used for that anyway.

Use case:

Tagged services must have interface. So fictional exporter:

#[AutoconfigureTag(name: self::class)]
interface ExporterInterface
{
    public static function getName(): string;

    public function export(User $user): string;
}

Simple implementation:

class JsonExporter implements ExporterInterface
{
    public static function getName(): string
    {
		return 'json';	
    }

    public function export(User $user): string
	{
		// convert $user to json string
	}
}

Real usage with autowiring (other cases also work in 100% same way):

class Exporter
{
    /**
     * @param ServiceLocator<ExporterInterface> $strategies
     */
    public function __construct(
        #[TaggedLocator(tag: ExporterInterface::class, defaultIndexMethod: 'getName')]
        private ServiceLocator $strategies,
    )
    {
    }

    public function export(User $user, string $name): string
    {
        $exporter = $this->strategies->get($name); // psalm now knows it is instance of ExporterInterface
        
        return $exporter->export($user);
    }
}

So in the above case, site visitors would pick name via some dropdown or button, and that value sent to Exporter class.

Potential problem:

None found for last 6+ months. The only issue I can think of is if someone uses ServiceLocator class in undocumented ways.

I.e. Symfony still allows public services but they are discouraged, and all documentation is using ContainerInterface; something that ServiceLocator extends.

But after testing it for long time, I think it is safe to stub it.

Updated:

This is the feature I mentioned, if someone is not familiar with it: symfony/symfony#39924