hmmm what's about renaming service session into .sesion, and create a deprecated alias sesion pointing to .session

In that way session is deprecated. but still overridable or injectable without drawback.

internal services will inject the .session service to not trigger deprecation.

internal services should be refactored IMHO to use the new approach :) if the session service itself is deprecated, no need for an alias id say.

if the session service itself is deprecated, no need for an alias id say.

issue is, we can't register 2 Session instances at the same time.
If we deprecate session, it can't be used internally (otherwise we'll trigger deprecation). That's why I setup the new FactorySessionListener.
BUT if people still use the session service (ie. injecting in the app's services) the application will break (because 2 distinguished instance of sessions are created by both the App and Symfony Internally).

A solution would be to check if the service is used to decide if the application should keep the old deprecated session service or if symfony internal's services should use the new mechanism. But checking if a service is used sounds very complex.

it can't be used internally

and shouldnt also :)

cant we create a deprecated service factory instead? session: { factory: ['@request_stack', 'getSession'] }

Ah, i figured. If the user created an overridden/independent session service, we need to account for it still.

Sounds like we need a check a la if ($this->sessionService !== $requestStack->getSession()) { /* deprecated case */ }, but im not sure this will trigger a depraction for the deprecated service, if so we need an intermediary .session service i agree.

Thank you @jderusse.