just think about how you would capture identifications in a table structure. right now, each identification – including ones resulting from taxon changes – is captured as a row in an identifications table. the activity stream merely displays each record in the table as a separate item in the timeline.
the way i read your original proposal, the way the identifications would be captured in the table would not be changed, but the activity stream logic would be changed to exclude some of these rows from the main timeline, attaching them to records that were not excluded and potentially overriding the display of data from the included records with data from the attached excluded records.
but if you’re saying “IDs wouldn’t be split in the first place”, then to me that sounds like you’re proposing to not capture taxon changes as separate identifications in the identification table. so then only the original identification would be retained, and its taxon and update date fields would be updated. but then to preserve history, you would have to create a separate identification taxon change history table that stores each change. this shifts some of the burden of history consolidation from the code that delivers the data to the code that records the data. it probably doss make getting the data in a consolidated format easier, but that complexity is still there when you go to record the data. so you’ll have to change a lot more stuff to go down this road, and it’s not clear to me that this provides a huge benefit.
i’m not sure i’ve explained this properly, but if you don’t understand what i’m saying here at this point, i think you would really have to just go through an exercise of trying to create a table or tables that show how you would keep a record of identifications and changes to identifications resulting from taxon changes, along with how you think the system is storing that data now. if you end up with two different very different table structures, i think that’s asking for a lot of headaches.