Forum OpenACS Q&A: Re: Compatibility matrix and OpenACS 5.7
They could be used as a namespacing mechanism; for example the calendar package might use a 'calendar' schema with a 'new' function within that schema (similar to oracle packages), and the function would be 'calendar.new' rather than 'calendar__new'.
Would there be any tangible benefit from doing so? Hard to say, it's mostly just a naming convention. But there also seems to be no downside, which is why wondering why they aren't used. (changing everything to using '.' instead of '__' is obviously a pretty big disruption of course)
The reason, why SQL schemas are not used in OpenACS is for historical reasons: when the postgres port was done, schemas were not supported by postgres. When using schemata, it would certainly make sense to move not only stored procedures into the schema space, but as well the tables defined by the packages, every package could be contained in a tcl namespace and sql schema ... and then, one should do the same for oracle as well. As you mentioned the benefit is not huge; from my experience is more likely that you get hate-mails, when you break something, than love-mails, when the components work as before.
I see a move to SQL schemas of less priority than Step-2 above (currently, debugging the function with the varying argument lists is painful, querying the default values from the postgres meta data does not work, we have hacks in OpenACS to work around this).