We are aware of that problem, and we are working into address it.
The first thing we are trying to warrant is in the case the user runs two times same Grasshopper definition over the same model with the same input values, no object is replaced even in different sessions.
The prototype we have is able to remember, between sessions, which component creates which element. When Grasshopper runs a new solution over the same model it is able to reuse those elements, but there are ocassions when the Revit API does not allow us to modify an element the way the user is asking for.
In those cases Rhino.Inside replaces the previous element with a new one. It keeps all the parameters from the previous Element that fit in the new one, this includes BuiltIn, Project and Shared parameters.
To talk about something specific, changing a wall base curve from a line to an arc implies a replacement, this is a kind of change Revit API do not allow.
An other example may be changing the sketch of a floor, there are ways of moving the edges, but if the change implies a new edge, as long as I know, the only way to do that is replacing the floor with a new one.
There are many others.
One thing we are also considering, for those cases where it is not possible to reuse the same Element, is to save the original UniqueId in the replacement and provide a way for third parties to acces it. This way a third party software will be able to know this “new” element is a replacement of the previous one and will have the possiblity of update their indexes acordingly.
We are “near” to release a version with that behaviour implemented.
I guess that would be easier to answer once it is released, but would that work for you?