Because an SD card can occasionally stall a write way beyond the delay setting, the only way to rule out camera hardware contention as a potential source of this error at this point, would be ....
Although I don't have a good explanation for that log, something related to file write timing would be very far down the list of possibilities. Somehow Lua on the camera returned something very strange, or some bug in the chdkptp code caused it to see the wrong thing as a return value. The file write timing thing will basically end up with the FsIoNotify assert, or maybe something with incomplete files.
If you have a suggestion how this signal could be implemented, I'm all ears 
Instead of issuing action_push_delay(conf.script_shoot_delay*100);
in AS_SHOOT, what should be done? Is this related to state_shooting_progress? If so, that variable is only set to SHOOTING_PROGRESS_DONE in core/main.c, depending on a propcase which is evaluated by shooting_in_progress() in core/shooting.c ...
That's part of the reason I haven't been eager to dive into it, just detecting when the file is done is only part of the problem.
A simple-ish way might be to make a function like shooting_is_save_complete() function and changing main.c to do something like
if ((state_shooting_progress == SHOOTING_PROGRESS_PROCESSING) && (!shooting_in_progress()) && shooting_is_save_complete())
shooting_is_save_complete() could just return true on cameras that don't have filewritehook, or use a flag set by PT_CompleteFileWrite if that turns out to work.
I'm not sure what potential side effects of doing this would be. You could also make AS_WAIT_SAVE wait for both SHOOTING_PROGRESS_ and shooting_is_save_complete(), or add a new stack item AS_WAIT_SAVE2...
It would be good to have the is_save_complete available from script in some way too, for people who use button presses instead of shoot(). We could put it in shooting_in_progress() but I'd be hesitant since that has always just reflected the propcase value before.
The other issue is that on cameras with native RAW and RAW + JPEG setting, FileWriteTask will be launched twice. This condition will need to be detected somehow.
File name ?

Since I don't want to cause chaos in the test branch, could you merge(?) the necessary changesets there?
There should only be a few s90 ones, they should be easy to move over.
Should this be done by simply merging all trunk changesets since the creation of ptp-remote-capture-test?
That's also OK, and would make could make the final remotecapture merge easier down the road, I'll try it and see what happens.