SPReprs directly represent the (simplified) parse tree of the XML document.
SPObjects are more efficient representations of the SVG data in a form convenient for quick updates; changes are often made here and periodically flushed back to the repr layer.
SPObjects are also responsible for updating a number of NRArenaItems in their care.
Populated by NRArenaItems, these essentially represent an incremental-update rendering context.
SPItem to NRArenaItem
Changes are typically first registered by internal methods, which change the SPObject and then call sp_object_request_modified() with flags indicating the type of changes that have taken place. The "modified" callbacks are responsible for updating basic state and propagating the flag changes elsewhere.
Later on, sp_object_request_update() is called, which calls the "update" signal -- it's the "update" handlers that are responsible for e.g. actually updating NRArenaItems and such. Usually (but not always) updates are done from the idle loop.
SPRepr to SPObject
SPObject initially retrieves its state (e.g. after being created) from an SPRepr when the "build" signal is serviced; at this time it may create/request_build() its children also.
The sp_object_invoke_build function, besides calling the object's build method, also attaches a listener to the source SPRepr (see ReprListeners) so that any changes to the repr that bypass its object (such as undo, which directly changes reprs, or changes done in XML editor) are caught and reflected in the object. This listener passes attribute and property changes to the "set" method, which dispatches them appropriately.
SPStyle to NRArenaItem
Currently, the NRArenaItem holds a reference to the SPStyle directly (bad!), but ... the details of this are still a bit unclear to me. SPStyles have no callbacks to speak of; I think the process is driven by the callbacks on SPRepr attributes (both property attributes, and the "style" attribute).
SPObject to SPRepr
To write state from an SPObject back into SPRepr form, request_write(); flags indicate how much data to flush back. The "write" handlers may create a new Repr if an existing one is not provided.