Within GEL (and your process that is performing the XOG), rather than take the 'last updated by' currently stored on the record, you can take the process instance ID variable instead (gel built-in value) and query the bpm_run_processes for the initiated_by field.
Once you have this, and a custom attribute on the object to hold the value for the 'xogged_on_behalf_of' user which you also audit, it should just be a matter of including that with your XOG write entry.
This would fix any issues of (near) concurrent UI updates by different people that then get XOG-audited as the same person since the process execution would be asynchronous. It's the same idea conceptually, but without depending on the changeable state of the row data whilst the process is in flight.
E.g. (describing a possible 'worst case scenario' without the logic revision proposed):
User1 makes change to the object
Process event fires for User1's behaviour, launches process1
User2 makes change to the object
Process event fires for User2's behaviour, launches process2
Process1 checks for last updated value on the object, finds User2
Process1 XOGs in the information, stores User2 as the user that made the change, whilst setting last_updated to the XOG account
Process2 checks for last updated value on the object, finds the XOG account
Process2 XOGs in the information, stores the XOG account as the user that made the change, whilst setting last_updated to the XOG account
In addition, I agree that it is better to avoid the unsupported code approach of directly manipulating the last_updated_by field values. Whilst not exactly the same as the scenario I wrote about in a blog post before, it is still a risky area to be interfering with as it explains: Impacts of direct database updates to the Audit Trail