So I'm quite liking the newly detailed error messages, but I'm not sure what the intended behaviour is now when trains go to a depot with cargo. Originally the train would be set to manual, which made sense to me as a "failsafe" behaviour since the train at least wouldn't be moving.

The issue I'm having is this:
I deleted a requester station while a train was on the way, to test how the system would handle such an event.
The train in question switched to manual, and the error message helpfully said exactly what was wrong (that a station in the train's schedule had been broken).
My thought, then, was to manually order the train to its assigned depot, where I assumed it would stay until I got the cargo emptied; I also assumed that sending it to the depot would reset the train's schedule. It seemed like a quick way to get the train out of the way, as one might want to in a live game to clear the tracks.
Instead, the train kept the original schedule (with the now-nonexistent station), and after a second of inactivity at the depot it proceeded on its way, looping through all the temporary stops and stations and back to the depot, over and over again. In a live game, it could have been quite tricky to hunt down.

My thoughts here:
1) Trains will generally not have leftover cargo in the first place (since they're given the "empty cargo inventory" condition for deliveries), so this problem shouldn't come up by itself very often.
2) Simply sending the train back to depot is probably not the ideal way to deal with trains that have broken stations in the first place, but it does show one way having cargo in depot could happen. I do know that giving each depot a "trash removal" inserter/pump would keep the train there because of the "1s inactivity" wait condition; is that the intention here?
3) I'm still surprised that the schedule didn't reset. In my testing map this resulted in the loop I mentioned above, as well as the train pathing to an unrelated station that had the same generic name as the deleted station (I named them all "---" since the name shouldn't matter).

Obviously, I could have gotten around all of this by manually clearing the train's schedule, then sending it to the depot, but considering how easy it was to have this happen (that is, having a rogue train running around with excess cargo) I thought I'd bring it up and make sure that everything is behaving as intended.

Addendum:
As a test, I deleted all trains from the network and made a single new one, put some stone in its wagon and sent it to the depot as I would any new train. The "held in depot" error appeared, of course, but persisted even after I took the stone out (I tried both by hand and with an inserter, as one might for "trash removal" as mentioned above). The error persisted and the train did not move until I toggled it from automatic to manual and back to automatic. That behaviour doesn't seem right to me, so I assume something is going wrong.

The train's schedule should have been cleared that sounds like a bug.

So the factorio api doesn't give a "train's inventory updated event" as far as I know, which is why it currently behaves like that. However I can set up a system to poll the held train periodically and reset the error if its inventory is empty.

Makes sense, I wondered if it might be something like that. It's not the worst thing to work around, since if things are set up right you shouldn't have cargo being taken back to depots anyway, but always good when error handling is as graceful as possible. Appreciate all the work you put into this mod.

I found it it will be fixed in the next version.