Currently we blindly accept the following co-ord system tags, and assume they are similar enough not to warrant conversion:

vp.definitions.sky_coord_system.utc_fk5_geo,
vp.definitions.sky_coord_system.utc_fk5_topo,
vp.definitions.sky_coord_system.utc_icrs_geo,
vp.definitions.sky_coord_system.utc_icrs_topo,

Essentially, if the timestamp isn't UTC, we ignore the WhereWhen section and drop the 'coords' table entry.
It shouldn't be too hard to implement conversion from all the time-system options (GPS, TDB, TT) to UTC using the astropy routines. Likewise it may be worth converting from FK5 to ICRS where appropriate for the sake of logical consistency, although the actual difference is small (<80mas).
We currently do not store a 'geo/topo/bary' (reference frame centre) field. Might consider adding this in future.

One the reasons for building voeventdb is to allow 'catch-up', i.e. recovery of voevents in case of a network or systems outage. You can already query voeventdb for recent events, but it would seem sensible to build a dedicated voeventdb-to-voeventdb 'sync' feature that ensures a full synchronisation of the databases (as judged by e.g. list of all IVORNs for VOEvents stored).

I have some very rough ideas about how one might do this efficiently (hashing IVORNs and comparing corpus-hashes, then bissecting to some granularity) but it needs thought and might be tricky to get right. Probably an inefficient but foolproof solution would be a good interim measure (even if feasible over local network only?).