SET CLASSLIB modifies global state, which is inherently bad if you want to use independent, reusable modules. I think this thread has already demonstrated one drawback.

At first it would seem that is more flexible to use unqualified names and to rely on SET CLAS, SET PATH, SET DATA etc. pp. to make those names available. However, more flexible it is not. In fact, it creates global dependencies and reduces flexibility because of the global coupling; it also requires you to have precise global control over all names that could possibly clash. For one thing it is impossible to run two versions of the same 'thing' side by side, for another it opens the door for all kinds of Heisenbugs because of the way Fox does name caching internally (especially for class names) and the haphazard fashion in which DBC-related names are resolved. And what happens when you integregate third-party code is anybody's guess ...

Unqualified names can allow some cute tricks but these tricks can become a liability unless you have total control over how the names in question are resolved. Basically this means that such names must at all times be unique within a compilation/runtime environment.

Using qualified and/or local names eliminates these problems. Sometimes this requires application-level glue code to pass some info to (and between) subsystems, especially regarding data paths etc., but stuff like this belongs into an environment/config module anyway.

Note: I am not saying that unqualified and/or global names are bad, but the fewer there are the better.