We are debugging an issue where the build version is not set correctly during a release build run. What we observe is that although RELEASE_VERSION is computed correctly once, when it is assigned to BUILD_VERSION in two different inject steps, it reverts to the previous value . 
My suspicion (without looking at the code) is this : 
envinject builds up a list of values to be played back into subsequent steps. When we add the same value twice, order is not respected. This means that either 
a) the values are played back out of order 
b) the values are not checked for collision 
c) the values are not allowed to be reset after being set.

We see the correct behaviour in any jobs that have only a single envinject step. We also see that additional env vars in the second step are correctly added, but "rewrites" of existing ones are not. 
This is a change in the 2.1.5 version of the envinject plugin.

Note : there was an unsettling change in this plugin at the same time, requiring all existing inject steps that contained windows paths that were not escaped to require escapement. This broke backwards compatibility, which should never be the case.

to clarify
during a release build, we set BUILD_VERSION, which we compute at two different places. it's set to the pom version, -SHAPSHOT, at the start of the run. After the release prepare step, we compute RELEASE_VERSION, and then inject BUILD_VERSION=$RELEASE_VERSION.
This last operation shows a correct RELEASE_VERSION, and an incorrect BUILD_VERSION

We initially set BUILD_VERSION using a groovy step, to SNAPSHOT
We then change BUILD_VERSION via envInject, and this works.
In a post-build step, we use envInject again to set unrelated information, and this causes BUILD_VERSION to revert back to SNAPSHOT.
The behaviour of the subsequent envInject has changed.