Okay, here is an idea. Given the imaginary identity relationship which causes the row to be inserted into party_approved_member_map, I don't think that the original statement of the problem matches up this. The party_in_tr is inserting the identity, who knows why it is there, since it could be assumed that every party is that party. But the only way to remove it is to delete the party. The party_del_tr deletes all rows in party_approved_member_map regardless of tag. But the relational segment triggers only delete the rows which have a actual acs_rels.rel_id. So the imaginary tag prevents the removal of this identity row. Obviously this should be necessary. This is the trigger statement that leads me to this idea:
delete from party_approved_member_map
where party_id = old.segment_id
and member_id in (select element_id
from group_element_index
where group_id = old.group_id
and rel_type = old.rel_type);
Anyway, in this case, the row is added by a trigger on parties, but 'not removed' by a trigger on rel_segments. This seems correct. But if someone uses a tag which corresponds to a real acs_rel, the identity row may be removed (maybe, not sure, maybe the tag should be changed to the party_id, since we know that id will never be an acs_rels.rel_id, or is there a guarantee that 0 will never be an object_id?)
So my question is: the data exists, but what problem is being caused by it? We never got any actual data rows, so I'm still not sure what would need to be fixed.
On a side note, Dave...the hardest bug to find is one which doesn't exist. But these types of bugs are easier to fix if you consider the possibility! Let's reconsider the actual issue.