This isn't so much a bug as a major design flaw, which is probably leading to all sorts of obscure bugs in a difficult to reproduce fashion.

The onSave callback is being called from a Unity Component's Update method, which is mid-way through a frame. This is hugely problematic in that event callbacks pertaining to the current state of the scene, have not yet fired when it comes time to save. Meaning mods can't possibly save accurate information to be loaded with the scene, because Lua's view of the scene is out of sync.

This flaw here is easiest to demonstrate when we consider object spawning. If we spawn an Object using spawnObjectJSON we expect the callback_function to be called the following frame with a valid object, one whose GUID has been set to a valid value. We can then store this GUID in a variable somewhere so that we can interact with the object from scripts (e.g. move it around on the table at the end of the turn etc.). When it comes time to save (onSave) we serialize this value, thus allowing us to restore our reference (GUID) when onLoad is called, so if we roll back time, or restore a save file we can still reference the object (e.g. remember to move it around at turn end).

Now, the problem here is pretty obvious:

1. We call spawnObjectJSON.
2. Unity creates the component.
3. TTS calls onSave.
4. TTS calls callback_function providing us with the GUID??? Whoops, too late.

The Unity scene has been saved with the object, and we've not saved a reference to said object. If a user loads this save, we've lost this reference to the spawned object indefinitely.
MonoBehaviour has an LateUpdate() method that can be used to solve problems like this. Everything in the scene should already be updated (i.e. Update has been called on every Component in the scene), it's only if you make scene graph changes in LateUpdate (which you shouldn't) that can cause issues.
One more thing to consider is that spawning actually takes more than 1 frame, so even if we were to simply use LateUpdate to save we may still get:

1. We call spawnObjectJSON.
2. TTS creates the object.
3. TTS calls onSave.

Next frame Update
4. TTS calls callback_function providing us with the GUID??? Whoops, too late again.

So, if we have any queued events callback_function, we shouldn't save, under any circumstances. We need to, at an absolute minimum, wait until are no queued spawn object callbacks.

I say at an absolute minimum, because if there are any other frame delayed events we should technically not save whilst waiting for them to fire either. However, spawning is the most obvious one as we absolutely need GUIDs to be able to save/load.

Of course, this issue only rears its head if we happen to spawn and save in the same frame. Strangely that's actually happening to me a lot. However, in some mods objects may not be spawned frequently. However, undoubtedly this logic will be responsible for some really obscure long running bugs that have traditionally been a real pain to diagnose and reproduce, particularly if players are trying to rewind.