Not quite sure I understand how to reproduce here, but bear in mind that CpsScmFlowDefinition is merely a convenience. For more control you can use CpsFlowDefinition (inline scipt) and just specify something like

node {
  checkout(…) // anything supported by the SCM
  load 'flow.groovy' // run everything else
}

That's what I did. I simply used the CpsFlowDefinition. Maybe my expectations where wrong, but this is what I was expecting to be able to do.

Freestyle project:
1. Define new job
2. Check "This build is parameterized"
3. Create string parameter with name "BuildBranch" and default value "master"
4. Under Source code management select "Git"
5. in "Branches to build" enter "* / $ BuildBranch"
6. when the build runs with the default value it checks out the master branch of my git repo and runs the build
7. If a developer runs the build and enters "feature/awesome" for the BuildBranch parameter, the feature/awesome branch is checked out from git and the build runs.

When I use the CpsScmFlowDefinition, I can do all of the above and select Git as the SCM and fill in "* / $ BuildBranch in the "Branches to build" text box, but git always complains that there is no branch named "* / $ BuildBranch". It doesn't seem to be resolving the build parameter.

The workaround @Jesse Glick proposes has one disadvantage: you have to allocate an extra node for the build, while using CpsScmFlowDefinition you don't.

mijay not if flow.groovy runs inside the same node it was given.

This is affecting me as well. The Help documentation for the field advertises it as a feature:

${ENV_VARIABLE}
It is also possible to use environment variables. In this case the variables are evaluated and the result is used as described above.
E.g. ${TREEISH}, refs/tags/${TAGNAME},...

So one of these is a bug.

Of course the inline help was written for the plugin when only freestyle projects existed.

jglick: I'm just saying, since this bug is several months old, it would appease me at least if the docs were updated to say something like "(Not available in Workflow Step; see JENKINS-28447)". Seems like a reasonable stop-gap solution, coupled with your suggestion above.

In fact, I'm willing to contribute a patch if you think that's worthwhile. And provided it's as simple a fix as I imagine – I'm not familiar with the codebase whatsoever.

Well this would apply to any SCM plugin that has any field which gets variables substituted, I expect. Have not investigated in detail.