I cannot speak for how this works, but for my mod it has a threshold of fuel which if it fall below it gets sent to the depot. If it is triggered to change, it applies the destination change immediately and resumes previous tasking after It basically inserts the depot temporary stop. Also consider that when you are also directing on destination full, then likely they may have recently visited a depot anyway and thus have recently been refueled if you set up that way so redirect for refuel almost never happen. What happens in practice in a large base with a large pool of trains, even when redirects for fuel happen it does not matter as another train in the pool will likely picked up the delayed tasking very quickly.
It is only really a concern when you watch a single train. When you watch the overall actions of hundreds of trains or more specifically the continuity of resource movement, then it becomes irrelevant.
This is what I found with my mod. Originally I was hoping to find a way to consider a minimal redirect of the original trip but in practice in a larger base with a large enough pool of trains it just doesn't matter and the extra complexity would just consume more CPU for no real benefit. Keeping it all simple to compute is good for large factories. While I have no idea what has been done here, I have to assume having solved some of these problem in a mod in an efficient manner that what they are doing is similar but also a lot better because they have much better access to make supporting core code changes than a mod developer has.
