symbol properties versus defstruct versus ?

This is really a general skill programming question.

I have a collection of skill procedures that all work together as somewhat of a package.  There is a need to have some common data shared among all of them.  This is analogous to the schRegPostCheckTrigger/schGetPostCheckTriggers/schUnregPostCheckTrigger/[schematic check code] procedures that are part of virtuoso.

Currently I have  a handful (15-20) of moderately short lists (typically < 10 elements) to be stored as well as maybe a few dozen boolean variables.  That is a lot of global name space pollution although I do have them consistently prefixed.  I've read the section in the skill users guide about using symbol properties as a way to control/limit the number of global variables.  However, I'm missing a few basic but critical steps.

1)  if I use a symbol with properties to hold all of this configuration data, it needs to be a consistent symbol so my procedures know how to find it.  gensym() creates a unique symbol when you call it so that seems questionable.  Or maybe I should assign a global variable to the result like:

when(!boundp('MYconfig)

  MYconfig = gensym("MYconfig")

 MYconfg->setting1 = "default1" 

 MYconfig->setting2 = "default2

)

2)  If I do this, it seems like I have to be more careful with loading the file with that gensym() in it first than the old globals way.  In the old way I could just do

when(! boundp('MYsetting1) MYsetting1 = "default value")

and it didn't really matter if you loaded this code before or after a user loaded settings.

3)  should I instead create the property list as a disembodied property list like this:

when(!boundp('MYconfig)

  MYconfig = ncons(nil)

 MYconfg->setting1 = "default1" 

 MYconfig->setting2 = "default2

)

4)  Should I reserve using the property list of a symbol that has a function binding for data which is used exclusively by that function but needs to persist from one call to another call?

5) Should I think about defstructs instead? The manual says the should be faster to access for the slots which were statically declared.  

defstruct(MYconfig_struct setting1 setting2)

when(!boundp('MYconfig)

MYconfig = make_MYconfig_struct(?setting1 "default1" ?setting2 "default2")

)

Then last, I'm trying to decide on a user or project configuring the code by direct setting of properties versus an API which gives a procedure for each.  The latter hides some implementation details (a good thing) at the expense of a proliferation of procedures which are just short wrappers around assigning values.

I know this should be basic stuff especially for how long I've used/written/hacked skill code... but it is never too late to improve.

Thanks

-Dan