The most-often encountered manifestation of this bug is this:
If you change the setting of both the key and the edge activating an action, the
edge setting is reset to the default (the value set up during the initialization
of the corresponding plugin) when compiz restarts.

This bug has been discussed in several topics of compiz.net forums, because it
manifests itself by breaking settings of several plugins. One of the discussions
(http://www.compiz.net/topic-2091-1.html) contains steps to reproduce the bug
with the scale plugin (http://www.compiz.net/viewtopic.php?pid=28158#p28158).
The bug has been reported, analyzed, and two solutions (a long-term one and a
transitional one) has been proposed in compiz.net bugtracker at
http://bugs.compiz.net/view.php?id=44 . A copy some bits from there follows:

________
ulph's analysis of the issue:

When gconfInitOption is called for an option of type CompOptionTypeAction there
are four calls to gconfGetOptionValue with the entries for key, button, bell and
edge (in that order). Suppose gconfGetOptionValue is called for the key entry
and that the key entry is set in gconf. Now gconfGetOptionValue will locate the
data structure for the action. This data structure holds the configuration for
both key, button, bell and edge. Next gconfGetOptionValue will update the data
structure to reflect the key configuration for that action. Finally it will call
gconfSetDisplayOptionForPlugin that will notify the plugin of the change and
write back the action to gconf with gconfSetOption. Since gconfSetOption writes
back the entire action data structure to gconf, the button, bell and edge keys
that haven't been read into our action data structure yet, will be overwritten.

________
ulph's long-term proposal

I propose that the gconf-structure should be changed so that actions are in
separate directories where all entries are read (and written) at once. That way
it would be easy to distinguish an action from some other key. The current way
that actions are retreived from gconf is kind of awkward. Also, this problem
would be easier to resolve. Do you think this is a good idea?

________
My (crankyjack's) transitional proposal

Putting [actions] into separate directories is logical, plus it will make [them]
look much neater in gconf-editor. The trouble is that this change is almost as
big as the move to the action system was. It will break current settings, and
requires new gconf schemas. So "Plan B" would be to change gconfGetOptionValue
so that it loads the four action options together. The change could be done as
follows:

    1. Move the ugly "heuristics" which determines plugin and option name in
lines 387--473 of gconfGetOptionValue to gconfKeyChanged.

    2. Merge gconfInitOption and the remainder of gconfGetOptionValue into a new
function gconfGetOption. It should take the same arguments as gconfInitOption
and load actions as a single entity. The function will have to synthesize the
gconf path to keys (the initial part of gconfInitOption) and call
gconf_client_get_entry.

    3. Call the new gconfGetOption from gconfKeyChanged, and replace calls to
gconfInitOption with gconfGetOption.

I think this makes sense, because gconfGetOption will do what its name says, and
will better mirror gconfSetOption. What it does in the current state is better
described as "gconfGetKey". Moreover, the function will not change much when
(later) actions will get separate gconf directories.