Thierry:
[The exception for CERL GRASS siblings is i.ortho.photo and the like:
send everything to /dev/null and code from scratch. It's a nightmare...]
FWIW the curses like interface has been dropped for grass 7, so the only
bits of i.ortho.photo that remain are the libs. The idea is to keep the
algorithms but rewrite the rest in a platform independent way. this needs
a volunteer interested in photogrammetry (& has for years).
I have better wording in french, but not polyline.
what is it?
In KerGIS, I have added a flag to encode the _function_ linking the
vertices
ie f(x) ?
I think the "problem" is the point of view. When keeping Sites
(singularities) apart, you see more that they are, too, a connected
network of control points to describe a surface.
Not necessarily, they may be historic locations of churches or sampling
stations, or any x,y,z[,t[,n]] singularity (not limited by imagination)
for that matter. Not just spot samples of some continuous surface.
There was a lot that could be done with the ASCII listing of sites
(there could have been a binary version for symetry to speed things)
and with Unix powertools that is difficult to achieve dragging topology
and so on.
that was a big strength for grass 5, but perhaps limited in its database
connections.
Triangulation, Delaunay are a critical part of what should be here in
a GIS (GPL GRASS has things as far as I know; KerGIS not for
the moment).
modern grass has those things, but they need some finishing touches AFAIU.
see past Google Summer of Code projects.
if you wanted to be a hero 
you could work on a BSD version of this:
http://www.cs.cmu.edu/~quake/triangle.html
(very well implemented but non-free for commercial use*, so sadly mostly
unusable..)
[*] I think that's fair enough if the author wants it, except for the
NSF (public) funding of it.
Hamish
