Doesn't really harm, but when a property changes, the binding will save it to the channel (blocking xfconf_g_binding_channel_property_changed() during the write), but since this is partly async because of dbus, the property-changed signal is emitted after xfconf_g_binding_channel_property_changed() is unblocked, resulting in setting the property again. Possible soluting migh be a async callback to unblock the property-changed signal, but this might cause problem, so it's not a good idea. Duno is it's possible to add something internally like xfconf_channel_flush(), which waits until everything is processed by/through dbus.
Yep, I'm aware of this. The xfconfd backend is smart now and doesn't re-set values (or re-send PropertyChanged) when you try to set a property to the value it already holds. I don't think there's a good way to fix this in the bindings without it being really messy, so I'm inclined to leave this alone.
Yeah, that's why I though too, but let's keep it open, maybe someone comes with something genius to fix this...
This is fixed because the property cache checks if the property is changed.