It seems to me that having a single update function that takes a bunch of keyword arguments, only some of
which can be used together, is not optimal.  On the other hand, I can see that it is the easiest to
implement since it also maps most closely to the Mozilla prefs.  An alternative interface would be to
have separate functions for each proxy type, e.g. new http_proxy("whatever", $port = <optional port>)
or new socks_proxy("whatever", $port = whatever, $remote_dns)

or new auto_configuration_proxy(...);

It does certainly seem that disabling a proxy profile should be handled by switching to a special
no-proxy profile or something like that.  Or maybe this no-proxy profile would just be called null? 
Also, why does there need to be a special list of proxy profiles?  Why not have proxy profiles simply be
stored as variables?  They could have an optional label field for display purposes.

As far as something other than the proxy mechanism changing the profile, I don't think the proxy profile
system should try to prevent the preferences from being changed by something else.  Instead, as you
suggest as one possibility, it can just add a watch on all of the proxy prefs.  If the proxy prefs change
under it in a way that matters (changes on prefs that don't have any effect due to other prefs can just
be ignored), it can either set the stored current profile to the no-proxy profile if that prefs indicate
that a proxy is disabled, or alternatively it can create a new un-named profile corresponding to the
current prefs.