The updatePlaces API allows modifying pages GUIDs, yet there's no notification for this sort of change. I think that the proper fix is to only allow setting GUIDs for new places (that is, calling updatePlaces for non-existent URI). Otherwise we're going to face all sort of bloody issues with the new Descriptors API, and very likely with the new bookmarks code as a whole. Should Sync actually need to modify GUIDs for existent places though, we need an API that notifies results for this change. Otherwise nodes would report the old GUIDs once the API for bug 627487 lands.

Update: After a long discussion with with Richard Newman and Marco Bonardo, it seems that for the time being (and at least until mid-2014) Sync must mess with GUIDs for places URI every now and then, potentially very often. This is a huge disappointment as it hurts both performance of future guid-based queries and the reliability of GUIDs as stable unique identifiers. That said, /I think/ we agreed that, for bookmarks, GUIDs can remain immutable as they are now. For new bookmarks, the API introduced in bug 914687 can be used. For the case of two bookmarks created on two machines, Sync would just "live" with the duplicates because (a) It's sort of expected from the user POV (bookmarking is an explicit user action, unlike history recording); (b) It's possible due to the fact multiple bookmarks for the same URI are allowed; (c) It would reduce the complexity we have to deal with by exactly 50% (and even more, because GUIDs are more important for bookmarks than they're for URIs, which are unique identifiers on their own). Long-term though (that's the mid-2014 note above) the Sync team has a plan for introducing their own unique identifiers for URIs, and at that point we'll make GUIDs immutable and optimize the queries to take advantage of that. *** Per that, I'm morphing this bug to cover just what needs to be fixed immediately.

See Bug 1012597.