I'm not sure I follow your first paragraph... P4_CHANGELIST is the last changeset id for the workspace, not the entire depot. On depots containing multiple projects, this will only be set to the last change that is synced for that specific project as defined by the workspace view. In this way, it already does exactly what you need it to do.

Are you just requesting that a variable be added that contains the changeset of the previous build?

Sorry for that, maybe this example might make things a little clearer.

Given the depot layout

//depot/project1/test.txt
//depot/project2/test.txt

Which contains the history

Change 1 by andrew@desktop on 2012/10/14 11:04:05
Added test.txt to Project1
Affected files ...
... //depot/project1/test.txt#1 add

Change 2 by andrew@desktop on 2012/10/14 11:07:12
Added test.txt to project2
Affected files ...
... //depot/project2/test.txt#1 add

If I'd set up a project in jenkins using the view map

//depot/project1/... //workspace/...

Which is simply a job that calls;

echo "P4_CHANGELIST = $P4_CHANGELIST"

Building this job after changeset 1 is submitted (before changeset 2 is submitted) I get the expected output

P4_CHANGELIST = 1

Then if I submit changeset 2 and build the project again I get the response

P4_CHANGELIST = 2

Am I misconstruing what P4_CHANGELIST represents? I'd expect it to be the changeset id of the last changeset associated with a project, but under all the projects I've used it with it seems to be the last sync'd changeset regardless of the workspace.

Output log of build #2 for Project1

Started by user Andrew West
Building on master in workspace /var/lib/jenkins/jobs/Project1/workspace
Using master perforce client: Project1
[workspace] $ /usr/local/bin/p4 workspace -o Project1
Last build changeset: 1
[workspace] $ /usr/local/bin/p4 changes -s submitted -m 1 //...
[workspace] $ /usr/local/bin/p4 -s changes -s submitted //Project1/...@2,@2
Sync'ing workspace to changelist 2.
[workspace] $ /usr/local/bin/p4 -s sync //Project1/...@2
Sync complete, took 17 ms
[workspace] $ /bin/sh -xe /tmp/hudson6120382511269786976.sh
+ echo P4_CHANGELIST = 2
P4_CHANGELIST = 2
Finished: SUCCESS

p4d version: Rev. P4D/LINUX26X86_64/2012.2/525804 (2012/09/18).
p4 version: Rev. P4/LINUX26X86_64/2012.2/525804 (2012/09/18).
perforce plugin version: 1.3.17
jenkins version: 1.485

Apologies for this, maybe this is a bug in perforce. Ignoring jenkins for the moment and going straight to the command line

Using the workspace path

andrew@www:depot$ P4CLIENT=Project1 P4PORT=www:1666 p4 changes -s submitted //...
Change 2 on 2012/10/14 by andrew@desktop 'Added test.txt to project2 '
Change 1 on 2012/10/14 by andrew@desktop 'Added test.txt to Project1 '

Using the depot path

andrew@www:depot$ P4CLIENT=Project1 P4PORT=www:1666 p4 changes -s submitted //depot/project1/...
Change 1 on 2012/10/14 by andrew@desktop 'Added test.txt to Project1

P4_CHANGELIST should always be equal to the last change submitted to the workpsace path, ie:

$ P4CLIENT=Project1 P4PORT=www:1666 p4 changes -s submitted //depot/project1/...
Change 1 on 2012/10/14 by andrew@desktop 'Added test.txt to Project1

It seems you are running into a bug. When you force a build to run that doesn't have any new changes it it's workspace, it falls back to using the last changeset from it's entire depot.

Code changed in jenkins
User: Rob Petti
Path:
src/main/java/hudson/plugins/perforce/PerforceSCM.java
http://jenkins-ci.org/commit/perforce-plugin/840c94ce920a7e43a89e21c409bb1a8d24ca6814
Log:
[FIXED JENKINS-15515] prefer workspace changeset before depot changeset