What does that mean for the mere mortals?  Is "steps" or "sh" the thing to avoid?

Never mind, I see the magic recipe.  I still don't know the exact difference between "declarative" and "scripting", but I am mortal as well....

the PATH+EXTRA system works for Scripted Pipeline. If it does not work for Declarative, please file a separate RFE in pipeline-model-definition-plugin. Workaround would I guess be something like (untested)

environment {
  STUFF = "${MTI_HOME}/linux:${MTI_HOME}/bin:${QUARTUS_HOME}/bin:${DCP_LOC}/bin"
}
// …
steps {
  withEnv(["PATH+EXTRA=$STUFF"]) {
    sh 'whatever'
  }
}

https://issues.jenkins-ci.org/browse/JENKINS-41339?focusedCommentId=357645&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-357645

The environment clause appears to be ignored by plugins executing code such as the following,

EnvVars vars = build.getEnvironment(listener); 

My current work-around is to define hard-coded default values for the pipeline "parameters", even for the agent "master" which runs on the same machine with the server. (If Jenkins server needs to run its own checkout of, say, a pipeline library, then it will fail to use Git on the server using the agent-targeting PATH).

    agent {
        label 'master'
    }
    
    parameters {
        string(name: 'FORTIFY_HOME', defaultValue: "/MYTOOLDIR/fortify", 
            description: 'A work-around to the plugin using FORTIFY_HOME of the Jenkins server instead of that of the agent')
        string(name: 'PATH', defaultValue: 
            "/MYTOOLDIR/fortify/bin:/usr/local/FOO/bin:/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", 
            description: 'A work-around to the plugin using PATH of the Jenkins server instead of that of the agent')
    }

I wish Jenkins in general its plugins in particular gave precendence to the agent's environment. I did not try to find the exact API to fetch that in the context of the plugin running on the server but aiming the given "agent".

Folks, I didn't notice this workaround but it does seem viable.  I use script vs declarative so you might need to tweak this a bit.

Yes, withEnv will not work within the inside closure.  Normally, the path variable will not be passed via a docker ENV method as that would usually be a bad idea given host OS and image OS are likely not the same.

So, if we know what the images path is, then we can augment the path via the docker run args field `.inside(...)` to achieve the end of path modification.   It does mean that I must know or obtain the original path from the image.  I own the image and the pipeline code so I can easily do that.  If not, then I'd run an ephemeral docker container, and get the path from that via shell + returnStdout

// hardcoded because I own the image or have determined what the image's path normally is
def knownOriginalPath="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

// my change to the path - in this case, a custom tool location used because I don't want to have to modify a bunch of existing pipeline code.
def pathModification="/ansible2.10/bin"
def desiredPath="${pathModification}:${knownOriginalPath}"


    docker.withRegistry(...) {
       // for now, the plugin seems to respect the integrity of the inside option string.
        docker.image(..)inside("-e PATH=${desiredPath}") {
            sh 'echo PATH = $PATH'        
        }
    }