That's why you are able to define the default node. If the plugin would not have priority over the "Restrict where this project can be run"-field, then the job would always run where this field point to.

The nodelabel plugin adds two new parameter types, node and label - maybe you better use the label instead of the node and define the default label with the value you otherwise would define in the "restriction"-field.

Thanks for your quick reply!

It's quite possible I just don't understand the best way to configure the setup. However, I don't think your solution will work for me...
Let me elaborate on my configuration: My master is Unix, while my slaves are Mac. I want to run the first and last jobs of a diamond build on the master, one of the middle jobs on a Snow Leopard Mac, and all other jobs on a Lion Mac. I have labels for each of these machines to specify their OS type and version. I set up the parameters for the whole build at the first job, and I pass them all to the downstream jobs (Perhaps I need to exclude the node parameter by passing all other values individually??).

If I do as you suggested above, and give a default label for either "master" or "unix", all of the jobs in the whole build will try to run on the master node or a Unix-labeled machine, respectively...regardless of what I specify in the middle jobs, which I want to run on Macs. Honestly, I'm not sure how your suggestion works any differently than specifying a node.

Ok, I think the only way you can do something like this is to use this plugin together with the 'parameterized trigger plugin',
see this section for https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin#NodeLabelParameterPlugin-BuildParameterFactory
...with this you could create some kind of coordinating job and use as many 'Trigger/call builds on other projects' in this job a you like.
Or you use the build pipeline plugin (although I'm not 100% sure if that's what you'r looking for) https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin

I realized I could get around this issue by having the first job run on the slave, and then splitting off a build trigger for each job that needed to run on the master, by choosing "Predefined parameters" which matched all of my current parameters except the node.

However, I found an underlying issue in the plugin that led to this problem. I've written up a new one to address it at JENKINS-12226.

sorry, but I don't think there is anything more I can do for this...