Note that the Container needs to be able to work without compiling down to a PHP file first, and eval is only limitedly possible. And adding to much extensions for the dumping process could lead to some hart debug situations and BC promises (as some will expect access to service variables $a).

You can already solve the configuration of a service after creation using a Configurator.
http://symfony.com/doc/current/service_container/configurators.html

Allowing to register CompilerPasses (classes only) in services.{xml,yml} file would be a good enhancement. But the PHP version of services.php files already support this (as it receives the ContainerBuilder) so I'm not if its use-case is good enough to support this in other formats as well 🤔

what about load time scripts and/or factory scripts? a use case came up exactly with annotation loader PR

container build code pushed down into config files could solve the problem (maybe its just my problem) of scattered container build resources

but using php as config file format is actually a good idea. some tools of the node.js environment use config files written in js, which has some beauty to it. but this still doesnt solve scripts ran during container "execution"

-1 for putting code in the config files to be evaled (because this is what you are asking).

If you want to have some code running at the instantiation time (your factory-script), you can (ab)use the service configurator for that (which allows to call a function to complete the service instantiation).

For your build-time logic, use extensions or compiler passes instead of trying to hide things inside services and asking us to eval it.
And for the load-script, we don't want people to be able to run arbitrary logic easily at this point, as it would impact performance. And in the case of the Symfony framework, you can use the boot method of the bundle to hook there (though the recommendation is to be careful with it due to performance impact).

but this still doesnt solve scripts ran during container "execution"

You can use a http://symfony.com/doc/current/service_container/configurators.html but it does mean your configuration is separate.

If you want to have some code running at the instantiation time (your factory-script), you can (ab)use the service configurator for that (which allows to call a function to complete the service instantiation).

Indeed.

-1 also. Yes #21837 is a hack. But we have already everything at hand to turn it into a non-hack if we wanted to do so: just create a factory or a configurator and implement the logic there.
We don't need "eval" variants as @stof explained.

didnt know about configurators before -- yes they solve the "factory-script" case
and boot methods can solve the "load-script" case

it still feels cumbersome to search in many different places (and often in 300+ LoC Extension classes) to find the piece of code responsible to build/configure a specific service/group of services.

Closing as explained.