Your are correct - lat/lon distances are not considered in this
module. This can be explained as - lat/lon is NOT finished. This is
just one example of many that doesn't work properly in lat/long.
However, the fix is easy enough, just slower. Use the
G_begin_distance_calculations() and G_distance() routines
(undocumented, still, of course) to calculate distance.
Another is d.measure - it only knows about UTM (planimetric, meters).
The idw (inverse distance weighted) algorithm makes rather poor
surfaces (to my way of thinking). Pits where it can't follow a trend,
etc. The literature is full of attacks on this, the simplist type of
surface interpolation method.
Try try r.surf.sor and see if you like the surfaces better. It handles
only raster based input, but allows the x,y units to be different than
the z units, does (almost) the right thing in lat/long. It is without
manual entry, but "r.surf.sor help" may be enough to get the idea. It
is iterative and you have to say how many iterations so this is a user
burden (without a good feel for how much is enough). It does have 2
features that act as workarounds: you can input a previously computed
surface as the starting point (ie run 100 iterations, then run 300 and
get a total of 400 in 2 runs) and it saves its output every 30 minutes
(you can change the frequency).
Michael