1. Thanks for pointing out the solution for tracking the current user’s contact id. I’m not certain it’ll be trivial, but you’re definitely right that a right combination of per-db-connection and per-CiviCRM-session updates to a MySQL variable might be quite enough to accomplish this.

2. As I mentioned in replies below, I think rather than extending the primary key to id+log_time we should go with a separate, auto-increment revision column and extend the primary key to id+revision, with the log_time column being there only for time-based queries. An otherwise-agnostic revision integer would also take care of updates happening during the same second, of course.

3. The last con means that you can’t *trivially* ask for the state of the database at the moment X; for every id-unique row you’ll need to check its last state with log_time < X (if exists) and the first state with log_time > X (if exists) and do some logic based on the action done at these points (whether it was an INSERT, an UPDATE or a DELETE). The other solution is to implement ‘windows of time validity’ for every row, which say that the values in the given row are valid between start_date and end_date – but I do believe such a solution (especially applied to our ‘main’, or ‘current’ database) would be an overkill.