I had (actually still have, sort-of) a similar issue for one of my large packages (Lattice, a beam-optics code available on the Maple Application Center). I originally tried to use an export for this purpose only to quickly realize that it did not work as intended. Presently I use a "Set" method to set certain parameters in the package, which works, sort-of.
Some requirements for any such mechanism I think are pertinent:
* Reasonable initial defaults so one is not forced to set the package defaults before every use (e.g. for small and simple sheets that use a package).
* Allowing to set only a subset of parameters, leaving the others at their original default setting.
* The ability to set or change such parameters after first use of the package in a worksheet without getting inconsistent results.
The last item can introduce a non-trivial complication in large sheets as any change needs to be communicated throughout the package. For in-part this reason I settled on using a Setter method with named parameters; this allows to do any kind of manipulation needed. Setting e.g. a member of a record implies any module-local routine affected would need to check the parameter(s) upon each execution. A Setter method also allows any kind of type-checking desired. I do like your name "Configure" however, as it implies a larger scope that "Set".
I don't like the use of globals. Modules are a great way of protecting the module-local variables; the use of globals penetrates that protection.
I am less concerned about name clashes. E.g. the "Set" method has a short name that may clash, but I can (and do) give other procs a longer more descriptive name.
I do not understand your comment about the configuration object needing to be separate form the package or module. If you do not use a certain package, why would you want to bother setting its defaults? On the other hand, would you want to always have to load your default-setting module? Maybe I am not getting something here...
My third requirement (changeability after first use of a package) can be debated. It stems from my need to set the beam energy in the Lattice package, which for many cases is not needed and the definition of which, in some cases, triggers extra and potentially time-consuming evaluations in the package. By setting it later I can avoid spending such time. It is not an entirely clean way of doing things, however, and I may want to change my approach to this issue in a later version.
Thanks for sharing your thoughts,