Precision of Z-coordinate Setup (reworked): 

Camera position:   (0, -6, 6);
Camera angles:     (45, 0, 0) (zyx rotation sequence); 
Camera resolution: X=64 [px]; Y=64[px]; 
Sensor sizes:      32 [mm] x 32 [mm];
  =&gt; px_per_mm:    2 [px/mm];
Focal length:      35 [mm];
Clipping:          Start = 2 [m]; End = 16 [m];


Object:            Plane orthogonal to z-axis located at z=0. 

[EDIT] Used 'Blender Render' not 'Blender Cycles'.

The depth map is determined by an easy-to-compute formula, namely:

 depth(x, y) = fy * sqrt(2) * L / (fy - (y - cy))                       (1)


Where: 

   L  = 6 [m] (height of the camera) 
   fy = focal length * px_per_mm = 70 [px]
   cy = y-coordinate of the principal located in the middle of the screen, 
        i.e. at 32 [px]


Then:

 depth(x, y) = 593.969696 / (70 - (y - 32))                             (2)


Saving the rendered image into an OpenEXR file 'plane.exr' allows to access the
depth- coordinate and compare it to the theoretical solution in (2). Save the
script below into 'extract_this.py':

import OpenEXR, Imath
import numpy 
import sys

pt     = Imath.PixelType(Imath.PixelType.FLOAT)
handle = OpenEXR.InputFile("plane.exr")

dw             = handle.header()['dataWindow']
x_size, y_size = (dw.max.x - dw.min.x + 1, dw.max.y - dw.min.y + 1)
array          = numpy.fromstring(handle.channel('Z', pt), dtype=numpy.float32)
array.shape    = (y_size, x_size)
it             = numpy.nditer(array, flags=["multi_index"])

while not it.finished:
    depth = float(it[0])
    if depth &lt; 10000: 
        y, x = it.multi_index
        print x, y_size - y, depth
    it.iternext()


The call it with:

&gt; python extract_this.py &gt; tmp.txt


will deliver the a data file with x and y in columns 1 and 2. The depth is
stored in column 3. This can be displayed with gnuplot:

 &gt; depth(y) = 593.969696 / (70 - (y - 32))
 &gt; splot "tmp.txt" u 1:2:($3 - depth($2-0.5))


and delivers a picture as shown below. A '0.5' is subtracted to account for the
fact that blender seems to deliver the depth at the pixel's center. As can be
seen, there is a line where the z-coordinate is simply off the track. What can
be done about that?
I think I found the problem.
Look at the diagonal in the picture, I just output the z pass, and get the high frequencies with substracting a blurry pass. Then the power node just reveals the error for the eye.

The effect is only with Blender internal, and not with cycles. There is an error along the edge which is the diagonal of the plane.
Now I'm not sure why it does this, but I think it's probably something like as said above:
&quot;Just an hypothesis, if the errors match the diagonal of the plane: maybe with floating point errors, the rays pass through the plane (on the edge), and then with sampling (I don't know if the z pass has several samples, for anti-aliasing, need to check somewhere) it mixes the good value with the 'inf' value, producing the errors.&quot;
Maybe the devs are aware of the problem, I don't know.
[EDIT]
In addition here is the same pass with cycles:

The z error is not here, AND the z seems to be correctly computed. I mean by this that with blender internal z is the distance between the geometry and the plane which crosses the camera, but in cycles z seems to be the distance between the geometry and the point from which the ray is casted (so on the sensor).
So here with cycles Z depends on Y and X, not only Y.
Also the white borders you see on both images are due to the blur combine with the power node, it's a normal effect.