We provide this already:

project.projectDir
project.build.startParameter.buildFileName

Does this solve your issue?

Yes it does – thanks.

The string "projectDir" appears once in italics in table 10.3,
and once in a pseudcode-ish variable name in 16.3.3
(bottom of page 51). In each case I'm guessing I read it
as a conceptual reference, not an an actual field within the
'project' object.

It's good to maintain a distinction between the
user manual and the reference manual, but currently
the user manual could probably do with a bit more
enumeration of what's available in projects & other objects
(plus a few more pointers to the reference manual).
I may have still missed something like "projectDir",
but something like that may have helped.

Wait a second.... I don't think projectDir actually works the way I'd expect.
Suppose we created the file /tmp/xxx.gradle to look like this:

createTask("foobar")
{
    println "user dir:    " + System.getProperty("user.dir")
    println "project dir: " + this.projectDir
    println "build file:  " + this.build.startParameter.buildFileName
}

Now let's 'cd' to '/' and run the command line:

   %     gradle -q  -b /tmp/xxx.gradle   foobar

What we get out is:

user dir:    /
project dir: /
build file:  /tmp/xxx.gradle

Notice that the user executed the command from '/' so Groovy sets
the system property "user.dir" to "/", as you'd expect.

The next line differs from what I'd expect to see:
the project dir (this.projectDir) is also set to "/", rather than "/tmp

Is the current behavior of "this.projectDir" a bug?
Should it be coming back with "/tmp" or am I misunderstanding
it's purpose? If so, what does come back with /tmp ?

The final line is not quite what I would have expected
(I thought I'd see "xxx.gradle", not "/tmp/xxx.gradle"),
but it seems like you could still say "that's reasonable".. maybe.
The thing that make me say maybe is that sometimes buildFileName
reports the file name as a relative path, not an absolute one.
Also, it would be nicer if the value always gave an absolute
path if it were going to go that route... as things stand, it gives
you a relative path if you're in the same dir & call the script
using a relative name

    % cd  /tmp
    %  gradle  -q -b  xxx.gradle foobar 

Think about what you'd like Gradle to do if someone said something
a bit crazy looking like:

  % cd /
  %  gradle  -q -b /tmp/../tmp/xxx.gradle   foobar 

Currently, it emits:

user dir:    /
project dir: /
build file:  /tmp/../tmp/xxx.gradle

That seems a bit wonky – if the build file is going to be reported as
an absolute path under certain circumstances, and a relative path
under others, then I'd expect that the path be normalized to "/tmp/xxx.gradle"
not left at "/tmp/../tmp/xxx.gradle"

If you have a chance, see also: http://jira.codehaus.org/browse/GROOVY-1642

Gradle has two command line options related to this, -p and -b.

This:

gradle -q  -p /tmp - b xxx.gradle foobar

should lead to the output.

user dir:    /
project dir: /tmp
build file: xxx.gradle

The -b property was intended to specify the build file name, not the path. It was assumed that the build file lives in the project root dir. So my first intention was to see your example as a Gradle bug in that it accepts an illegal option argument. But on the other hand why not allowing to specify a build file path separate from the project dir. Then we have two other bugs. The -b property should be described as 'assign build file name, and the start parameter property should be called buildFile. And the latter should not be of type String but of type File and would be normalized at construction time.

I have filed: http://jira.codehaus.org/browse/GRADLE-368

This will also solve Gradle-366.

I've added Project.buildFile, which returns a File whose path is the canonical path of the build file. I think this should solve the problem.