In PINES we get multiple helpdesk tickets per month from staff who can't figure out what happened to items after a transit is aborted. When system adminstration staff are asked to investigate, we can only glean so much information from the database since the "abort transit" process deletes the action.transit_copy row from the database, leaving gaps in the chain of custody of the item. My suggestion is to add a "cancel_time" row to the action.transit_copy table (which would in turn be inherited by action.hold_transit_copy and action.reservation_transit_copy). I'm working on a branch now.
On a side note, when searching for possible duplicates for this request, I came across bug 1570091, in which the language "Cancel Transit" is being used in the web client. I support a move towards the "cancel" term over and above "abort", which is at best programmer-y and at worst potentially inflammatory. I intend to change "abort" to "cancel" in the branch I'm working on for that reason, but I'm open to opinions or discussion.
I'll confirm on the user end that this is an issue - aborted transits can cause serious problems when you're trying to track down a missing item.