The :vlr-Erased callback should not remove the reactor with (vlr-remove) because then if someone erases it and later brings it back with the OOPS or Undo command, the reactor will be gone and nothing will react to the :vlr-UnErased event. Instead you want the :vlr-Erased callback to remove the persistance and the :vlr-UnErased callback to put it back. if somone erases the object, the reactor will just hang around waiting for the object to get unerased. If it is never unerased, the non-persistant reactor will die when the drawing is closed.
Have you tested the latest routine yet?
I did exactly what you are mentioned in my early routines with reactors... One of the concerns to find an easier way to solve and get the UNDO mechanism without the use of the unerased event, was to use what I posted.
Mostly because, when you have a routine with reactors to run several times, basically a VLISP programmer would tend to create every time a new reactor per each call, in this case it is just a single object[owner]... what would happen if they were 4,5,6,10...
So, I end up killing the reactor in the erased event... and not worried of having any problems, if I not end up using the unerased....
The last routines I did with object reactors basically I simple implement a "reactor per object", in example if one routine was using four objects, and the user call it 100 times, the routine only was using 4 reactors, instead of 400 per say....
Have fun.