Currently (Sept 2014) the sitemap is created on request by the server, and is only requested by the client as the site is added to the neibourhood. This has a consequence that any new or updated content, or pages, will not be reflected consistently in the client's view.
Possible Solutions
Rather than create the sitemap on request, the server should keep an up to date version, and update it as site content changes.
Server-sent events - see Streaming updates with server-sent events 
. Issues: CORS support patchy, not supported by Internet Explorer.
Polling, Long polling & Websockets - discussed in the article linked above.
User Interface
Having a sitemap update could have knock on effects in the user interface.
A displayed page may now be out of date - includes 'Recent Changes' and ghost pages.
A twin of a displayed page may have been updated. Twins could update showing an older page becoming newer.
There are cases where the same user updates a page from two different tabs. The client code could know this without talking to the server.
There are cases where the same user updates a page from two different computers. The client code wouldn't know this without talking to the server.
Resource Considerations
We should consider how many open connections can be maintained. For example, if a user had 15 tabs open and had 15 sites in each tab's neighborhood, would that be too many open connections?
The current naive implementation of sitemap reads every page to build a map on demand. If sites were smarter about incrementally updating the map then they could share this change information in a much more efficient REST call.