* In fact, because of the missing guarantee for their unchanged
* survival of updates, they should be copied under a modified name
* into private code rather than called from the main GAP library.

I would indeed sugget this policy except for code which users of GAP
recontribute to the GAP effort, and which proves useful. This could
lead to faster (but managed by the maintainers) growing of GAP, as
people writing _good_ code would get the chance to have their time
rewarded by growing an 'undoc' function into a documented (or at least
supported, note the possibilities in this difference) one. The GAP
project would gain through contributes of decent code.

This is kinda the way the Linux project works, where I put most of
my efforts, and I can tell this leads to _extremely_ good and relyable
code, though the possible flow of the system might scare maintainers
at first.

But, taking a look at how other people would implement things, and
never thinking of oneselfs ideas as the greatest and only is what
makes a developer of compicated systems as GAP.

Concluding, I'd suggest letting those who can handle it deal with
the internals, and look _close_ at how and why those people did this
and maybe get some ideas for GAP for free.

Eddie.
ecd@skynet.be