I think the deal is this (you are right):

1. Cells-reset has always reset the vital *data-pulse-id* to 0
2. Old model object cells still in use when cells-reset was invoked thus have always had DPs (datapulses) greater than *data-pulse-id*, obviously benignly so in your application.
3. I have an insanely high degree of confidence that the assertion above was inserted in the past month after I debugged a tough problem in which an object DP got moved backwards. (This had to do with another new mechanism,integrity bubbles, which I happen to plan to back out.)

So...you can:

1. chop the assertion
2. suggest a new cells-reset-a-little, or a cells-reset parameter which says "I want to reset this but not that"

Re the latter, i admit Cells are a little un-Lispy in that I have not worked much on restarts. But the function cells-reset is meant to truly reset the cells mechanism, so as you surmised I am surprised you got away with it at all. I almost think then that, in your testing, you might want to simply arrange things so that cells-reset does not get called unless you are truly reinitializing your own application -- that is the spirit of cells-reset.*

kt

* uh-oh, now I am in a panick over someday doing persistent cells again. :) look for datapulse-id to become:

        (+ (* 10000 (get-internal-real-time) (incf "oldskool-dp*))

Where *oldskool-dp* gets zeroed when g-i-r-t changes.

kt