StepContext.get(EnvVars) is advertised as an option and when run inside node you would expect it to include all environment variables associated with that Computer, but it does not: it only includes those added by Computer.buildEnvironment (node properties, JENKINS_URL), plus anything extra added by the node step (JENKINS_SERVER_COOKIE). This did not matter to sh steps because LocalLauncher.inherit started with the existing environment variables and just added in the overrides. It also did not matter for env.PATH calls from Groovy because EnvActionImpl was hardcoded as of 8eb96e8 (0.1-beta-7) to look up a Computer as a fallback value.

I think the right fix is to make PlaceholderExecutable do the call to getEnvironment, then make EnvActionImpl look for EnvVars in the context—also giving those precedence over user settings, for consistency with DefaultStepContext.

WorkflowTest.env is also too weak: it does not even test externally set environment variables, does not test per-slave variables (which would presumably require a mock SlaveComputer.getEnvironment override), and does not test EnvVars.override behavior (PATH+X syntax) from a block step.