You don't have to actually render a glyph (in the sense that it
is rasterised to a pixel map) to analyse the vector coordinates.
Just run through the 'glyf' table at the correct index, and resolve
the coordinate list.

Well, you haven't understood the problem, I believe: If you ask for a
bounding box which returns font units, you get *exact* values.
However, if you ask for a bounding box at a given DPI value, returning
pixels, you can't get an exact answer without rendering the glyph, as
the image in the above cited email clearly shows.

I did (on both accounts), and perhaps the phrasing of my mail was
misleading. I did not mean to suggest that what I suggest solves the
problem -because of course raster coordinates are not glyph box
coordinates- but I did mean for this function suggestion to be considered.

Basically, it'd be nice to have a function that returns the
pre-rasterised coordinates, so that a programmer has more accurate
numbers to work with. Knowing the desired font point size and dots per
inch will then allow a programmer (if they so choose) to do any custom
arithemetic to determine the "true" bounding box in whatever raster the
text will end up in.

Esssentially, getting the bounding box in pixel units with the implicit
promise that things will go wrong without a way to obtain the
pre-rounding data seems like something that can easily be resolved, and
would give programmers more power in dealing with situations in which
rounding introduces an off-by-one-pixel value. As a new function it
won't alter the functioning of any existing code, but would offer a
finer-grain control to the programmer.

So again, see this as a recommendation in relation to a problem that is
highly related to, but not quite the same as, the original poster's
problem. If you have access to values before and after they get rounded
lets you perform corrections (and tricks) that are impossible if you
only have access to rounded-with-possible-error values.