If one has an instance of Mail::SpamAssassin, and one calls
"read_scoreonly_config" (a very unintuitively named method, I might add, since
it reads things that aren't scores) on a file, the various settings in that file
replace (or augment, in the case of whitelist entries) the corresponding
settings in the currently active Prefs object. The problem arises when one calls
"read_scoreonly_config", processes an email (presumably using the preferences of
the individual who owns the config in question), and then calls
"read_scoreonly_config" again with a different file to process an email for a
different user. 

For example, assume that I have in my "local.cf" the setting "report_safe 0".
Now I call "read_scoreonly_config" on a file that contains "report_safe 1" and
process an email. Everything works fine. Next, I call "read_scoreonly_config" on
a file that doesn't contain the report_safe setting at all. The user who made
that preference file assumes they will get the system default setting of
"report_safe 0", but they will in fact get "report_safe 1" because it is not
overridden by reading the new config file. 

This is not a problem when "load_scoreonly_config" is used in spamd, because it
uses fork() to create a new child every time it processes a message, and so any
scoreonly config loaded is only loaded in that child's copy of the
Mail::SpamAssassin object. But on a Win32 system, for instance, where fork() in
perl doesn't work too well (at least not in perl 5.6.1), it can cause problems.
This is specifically in the context of a filter I've written for CommuniGate
Pro, called CGPSA (<http://www.tffenterprises.com/cgpsa/>), which uses
Mail::SpamAssassin directly.

While it's possible that some programs depend on this behavior of
"load_scoreonly_config", I think it's unlikely; it would be much more reasonable
for "load_scoreonly_config" to start from a base configuration (the rules files,
plus local.cf) and then modify that configuration with the loaded config file.
If that change is not something reasonable to implement, an alternative way of
getting this functionality without creating a brand new Mail::SpamAssassin
object for each loaded set of preferences would be most helpful.