Not off-hand...but if you send me a private email (so that I can get yours...my profile has email info), I can forward the old P&T doc which has the detailed discussion as well. It was termed (at the time) the "missing update" problem, but it could affect "missing deletes" as well. The underlying issue is a locking optimization that was added for datarows locked tables as well as the optimistic locking added in ASE 10.0.... For example, in 4.9, if you tried a delete and the row wasn't there, we would have held the lock until the txn committed. With parallel DSI's, remember, the inserts, updates and deletes are being executed in parallel - it is only the commits that are sequenced. So a rapid insert followed by a separate txn with a delete could be sent on two different DSI threads with the insert at the tail end of the first thread and the delete at the beginning of the second. As a result, delete would execute first - zero rows affected (also trapped in later RS releases as dsi_rowcount_validation) - but also no blocking lock for the later insert. If the lock would have been held, it would have raised a deliberate conflict and PDSI would have backed out the txns and ran them serially.
There are several ways of treating this:
1 - prevent universally by using (with RS 12.6) the dsi_serialization_method of isolation_level_3
2 - minimize the risk to acceptable by using dsi_partitioning and specifying a rule - for example, if you know that it was the same SPID that did the insert/delete, then you can set a partitioning rule on session_id that would prevent it from happening without requiring full iso 3.