With the EnvInject plugin, environment variables are injected at runtime.
Reporting environment variables are post build.
For matrix jobs, there is a dedicated report on each configuration and there is not inheritance from the parent job.

Knowing if a environment variable has been injected as a pre build or as a build step is not so important for me.
Could you give more use cases?

The reason behind this issue is the fact that configuring a jenkins job in the means of using env variables is quite difficult because of the many checkboxes and textboxes placed all over in jenkins.

System Configuration
I have the possibility to configure global - master node/systemwide options. There I get the hint that node/slave specific settings might exist too. The 'Unset System Environment Variables' checkbox is really nice, I do not get any clue what kind of variables might be set at this point nor do I have control of enabling/disabling at variable level here.
-> a list of master variables injected from this point would clarify much I think

Node Configuration
Again, I have the option to enable/disable preparing a job environment and fairly the same options as at system level above but probably still have no clue what impact to my job it might have.
-> a list of node specific variables injected from this point would clarify again I think
-> at this point a comparison of variables/values against master would potentially help to find out which variables I really need to redefine as they differ from master.

Job level configuration
The complexity increases again as I now have the possibility to enable/disable 'Keep Jenkins Environment Variables' and 'Keep Jenkins Build Variables' but have no clue what exactly I do unless I run the job several times and try to build my own paper variable comparison matrix by using the fairly helpful 'env' shell command which is the only tool I can use to inspect - at least on unix like systems.
-> at this point I can spend hours reconfiguring the job including master/slave node settings and build it again to see what changes in environment variable settings I get.

Black magic
Finally there are parts of the system I might not have any control at all. For example I can not redefine the WORKSPACE variable in a multi configuration job using environment variables in such a way that I can get rid of having ($axislabel/$axislabelvalue)* appended anyhow. At least such an override - done by using the cool groovy script feature - has no effect on the SCM checkout as it still used the pre-override value

I really appreciate what you have done so far but if these things could be made more transparent to the user it would be much easier to get a job correctly configured and running in less cycles/time.

I have difficulty providing this feature at the moment due to the plugin design.
Regarding the ability to override the WORKSPACE variable for matrix projects, it is maybe a bug, please report a new bug.
Moreover, would you like also to have the detail of injected environment variables at each job step (before checkout, after checkout, build steps, publishers)?

Surprisingly the WORKSPACE variable thing resolved itself when I switched over to use the Groovy option to prepare the variables and I didn't test again using the conventional way.

I think it only makes sense to print env vars before a steps when I am able to adjust the values between. Otherwise they would probably not change at all.

Please make a new issue and provide an isolated scenario?
Thanks