Agreed. The nature of replaceable lists lacking version reconciliation in a decentralized environment makes for a major risk of data loss or clobbering. I’ve been stewing on the idea that old replaceable list events should not be deleted implicitly, and that there should be an additional tag for every new list event that indicates the event id of the old event it intends to “replace”. If a client encounters a series of events for the same list, it should allow the user to determine how to reconcile if there’s branches in version history. I’ll put out a PR to NIP-01 to see what people think but I imagine it could be controversial as it adds a layer of complexity.