This is a versioning bug in the presence of restore and transactions. It's hard to reproduce and seems memory-layout dependent.
At the moment I only have a jython testcase, see below. This is with a svn checkout from today (442228).
Basically the program does create a node and subnode and do some checkins, checkouts, restore, modifications, in successive transactions. Transactions are managed manually using the xaresource API, but it would be equivalent to use a UserTransaction (the sequence of xaresource calls in the end is the same).
The program log and stack trace is:
File "debug1.py", line 128, in doit
File "debug1.py", line 145, in ?
Caused by: org.apache.jackrabbit.core.TransactionException: Unable to prepare transaction.
... 22 more
Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: 36eca6a5-8e5d-46a8-897a-4b81734aaad4/
predecessors has been modified externally
... 23 more
Note that the mentionned property (here, "jcr:predecessors") has changed when I was cutting down on the program size to get a simpler testcase. It's not necessarily a "system" property, and sometimes it was property of the subnode created under the main node.