A regression has been introduced in this commit:
https://github.com/jenkinsci/pipeline-maven-plugin/commit/c7d85c5291603ecff2c721f2255e18d9b9175a4e#diff-faa9e5307f768068d1e5a7fa655b44b9R310
When there are spaces in the job name, and thus the workspace path (and its associated temporary dir), the generated $MAVEN_CONFIG variable is no more always a valid list of mvn command line options. The Maven global and user settings files are in the job's tmp dir, and thus can have spaces in their path, leading to something like this for a job named "build Something":

 [jenkins-maven-event-spy] INFO generate /home/jenkins/workspace/build Something@tmp/withMaveneb8f05cc/maven-spy-20171127-120841-7484912681885066084612.log.tmp ...
 [ERROR] Error executing Maven.
 [ERROR] The specified user settings file does not exist: /home/jenkins/workspace/build
 [Pipeline] }
 [withMaven] One or multiple Maven executions have been ignored by the Jenkins Pipeline Maven Plugin because they have been interrupted before completion (1). See Pipeline Maven Plugin FAQ for more details.

Also I've not tried, I assume that using a job specific Maven local repo could trigger a similar issue (through the -Dmaven.repo.local=... argument).

This used to work fine in 3.0.2, because ArgumentListBuilder was doing the right thing (quoting in toString()) to generate the complete command line. Fixing this in 3.0.3 is not obvious at first glance; the whole idea of using a string environment variable ($MAVEN_CONFIG) as a list of command line arguments is wrong when you don't have enough guarantee about what these arguments look like.

I understand the change was introduced to better support "mvnw" from Takari Maven wrapper. Maybe one option could be to not use this variable in the "withMaven Wrapper script"? (keep using an ArgumentListBuilder to generate your wrapper, and leave the broken $MAVEN_CONFIG thing to users of the mvnw script)

Or issue a warning message when you detect spaces in the workspace path?