When I looked at this I started out recording the before and after file counter values to see how often the loop went to the full delay period. On the cameras I have that are affected by this it happened very rarely so I decided to stick with a simple solution. It's no worse than the previous code and in most cases exits the loop after 10 - 20ms.
I don't have direct experience with this as AFAIK none of my DryOS cams is affected. It's also not a question that it's better than the fixed delay.
There's no guarantee that capturing the file counter in capt_seq_hook_set_nr will behave any differently - the call to this is not that much earlier than the call to capt_seq_hook_raw_here and there is no sleep between them
capt_seq_hook_set_nr, wait_until_remote_button_is_released are all called before the shot, the raw hook is called after it. I've traced back the update of the file counter param on a DryOS cam (don't remember which, maybe A470), and it seems that the task responsible for it is DvlpSeqTask.
so in all likelihood it would get the same file counter value.
That could be true, I don't know when the other task decides to increment the counter, the shot will happen anyway at that point. shooting_expo_param_override is called before decision, but it's in a different source module and in some ports it might even be skipped, so it's probably not entirely reliable (could result in overwritten files).
So, in short: I don't know a better solution that doesn't require messing with every affected port's source.