See #20688 for the unresolved part.
If someone wants to give it a try, displaying could be done using a combination of $container->resolveEnvPlaceholders()' $usedEnvs arg + $parameterBag->all() to get the default values.

I don't know if the Yaml dumper supports dumping comments as in the suggested excerpt.
I think it'd be much easier to dump the parameter section with default values for all env params that have one.
Btw, we don't display the value of other params, so why doing so for env params?

@nicolas-grekas debug:config actually dumps the config with resolved values for non-env parameters, not their placeholders. But maybe I misunderstand

@nicolas-grekas In fact, we are both right: they are only half resolved
See #20714

So, in #20704, I fix the buggy part, yet env vars are not replaced by their actual values for now.
To me, resolving the values, being for remaining unresolved regular params or env vars should be discussed and changed in 3.3. The current behavior is also useful so I don't know what's the best as far as DX is concerned.

I'm closing this as "fixed" because I've tested this with 3.3 and 3.4 and it works as expected. Replacing the env vars by their actual values should be considered as a different feature. Thanks!

This is actually still broken in Symfony 4.1.1 as it crashes validation.

For example if using this in a bundle configuration:

                ->scalarNode('my_api_url')
                    ->isRequired()
                    ->validate()
                        ->ifTrue(function ($val) { return !preg_match('#^https?://[^\s]+$#', $val); })
                        ->thenInvalid('"%s" must be a valid URL with http/https scheme')
                    ->end()
                ->end()

And then configuring this as:

  my_api_url: "%env(MY_API_URL)%"

The debug:config will crash:

  Invalid configuration for path "mybundle.my_api_url": ""%env(MY_API_URL)  
  %"" must be a valid URL with http/http scheme           

@curry684 in this case that's expected: how dear would it be possible to validate at compile time a value that is known at runtime? Env vars are not compatible with every situations. At some point, this has to be supported case by case, option by option, by refactoring the code to use runtime factories that embed some validation. But only when it makes sense. Turning all options to dynamic factories would basically mean turning off compilation. Not wanted either.

@nicolas-grekas I'm not saying it can be fixed by showing an unknown mutable value, I'm just saying it's not DX-friendly that it crashes completely. We could surely fix debug:config to instead print %env(MY_API_URL)% in a different color instead.

Also, in my specific case it wouldn't have had to crash as MY_API_URL was both present in %project_dir%/.env and available in the Docker container I was executing the command in.

There's certainly room for improvement there over a blunt validation exception, as it more or less obsoletes debug:config in many applications for many bundles 😉

But no, if it were an easy fix I would've made the PR already, or opened a separate issue, over remarking here that the discussed behavior is still broken in a lot of cases.