The relevant code being:
I'm seeing that the first object modified ("left") is updated, but the second is not.
Tracing through the Isis and JDO code, it seems that the left object is dirtied, and then this is flushed when the right object is subsequently modified, because - by default - JDO will flush a first object once a second object starts to be modified; see http://www.datanucleus.org/products/datanucleus/jdo/transactions.html and "datanucleus.datastoreTransactionFlushLimit" property; to whit: "represents the number of dirty objects before a flush is performed. This defaults to 1"
So the action finishes with the "right" object still dirtied, so far as JDO is concerned, but not yet flushed.
The reason that JDO doesn't flush is that the new auto-clone functionality for JAXB view models means that we end up creating a new view model, and this new view model causes the PersistentEntityAdapter.class that in turn calls BookmarkService#lookup, which in turn calls Isis' PersistenceSession and finally JDO's PersistenceManager#refresh(...). This ends up trampling over the state of the "right" domain object.
The fix is to extend BookmarkService's API to provide an option as to whether to overwrite or to merely lookup an object. To avoid breakage with existing applications that might rely on the current behaviour, the default will be to overwrite.