I have been working recently on dealing with some anomalies in the system relating to waiting times. I am currently part-way through that work, which consists of three separate revisions to the code, being:
(1) increasing the rate at which old waiting times are made stale and discarded or diluted;
(2) storing the estimated waiting times separately from the actual waiting times, and also updating the estimated waiting time when necessary; and
(3) introducing specific logic to deal with the case where a convoy arrives for a ware packet's ultimate destination, that ware packet is routed to go to its ultimate destination through an intermediate stop, and the direct route would be faster than the planned route.
I have currently completed the first two (the second was particularly tricky and needed extensive testing of various ways of doing this, which is why I have not had much time to respond to other bug reports or even the very helpful work by A. Badger in identifying the cause of some bugs in other areas in the last few days, as well as having been busy with non-Simutrans matters all day yesterday), and the third is outstanding. The first should, at the date of writing, already be in the nightly executable, and the second should be in to-morrow's nightly executable.
The third is yet to come, and, whilst it does not immediately appear to be directly relevant to waiting time, is in fact a fix for the anomalous behaviour reported here
(as well as elsewhere on other occasions by other players). Because this was not a bug in the narrow sense of an implementation failure, but rather the code working as designed, but the design leading to anomalous behaviour in some situations, it requires some careful thought to resolve.
The basic problem is this: if a transport line - in Fam621's case, a railway line for passengers (I shall refer to passengers here, but, aside from journey time tolerances, this also holds for mail and goods) - has insufficient capacity, not enough people will be able to get on when each train arrives, so some will be left behind at the station waiting. That number will continuously grow as not all passengers will be able to board each passing train. In Simutrans-Standard, this would grow forever unchecked, leading to absurd results with stations having numbers of passengers waiting equivalent to the population of medium sized towns (some tens of thousands).
In Simutrans-Extended, what happens is that the waiting time will increase as it takes longer for each set of passengers to be able to board the train. There will eventually come a time when the routing system determines that some other route than the direct route is actually faster (because the waiting time is now so high), and, in any event, the overall journey time would be so high that fewer passengers would want to travel, the increased journey time owing to the higher waiting time putting the journey time above many passengers' journey time tolerances. This is precisely what is intended: an realistic mechanism to limit overcrowding by the use of economics (the limited resource being journey time) and an optimising algorithm (the path explorer in this case, which optimises routes by time).
However, this can then lead to some odd results in some cases. Because the path explorer can only ever determine a single route between each origin and each destination (any other system would be too computationally intensive for larger maps), at the point that an alternative route becomes the faster route to the ultimate destination due to the excessive waiting time, all passengers will always take this route, meaning that no passengers will take the original, direct route, even though it will now probably not be overcrowded at all, since all the passengers will be taking an alternative route. This means, in turn, that empty trains (etc.) leave the station bound for passengers' destinations, which they do not board because they assume that the waiting time will be too high. Worse, because nobody is now departing for the relevant destination using the particular route, the very high waiting times remain for a long time because they are not overwritten with new, lower waiting times.
The only way to deal with this within the limits of the current routing system is to have logic specifically to test for this case, and, whilst it continues to route passengers (etc.) using the optimal route as currently calculated, including the waiting time, if any passengers/mail/goods are bound as their ultimate destination (not merely next transfer, as this cannot usefully be tested) for a stop for which a convoy standing in the current stop is headed, to check whether the arrival time of that convoy at that destination stop indicates a lesser journey time than the overall journey time estimated using the optimum route. It still has to check this, rather than automatically boarding the convoy if it is bound for its destination, as this convoy might be drastically slower than an alternative (going the wrong way around a circular route to the next stop in the opposite direction, for example).
As may be apparent from the description above, more quickly refreshing older waiting times should also contribute to returning some measure of equilibrium to under-capacity routes within a more reasonable time.
As to the second of the features, somebody had posted some time ago (I cannot now find the post) about adding 'buses to a newly created line, and the waiting time would be stuck at the estimate based on the frequency of a single 'bus using the line, which often meant that nobody would use the line because walking would always be faster than the long waiting times, which would not be cleared even if more 'buses were added. Now, the estimated waiting time is treated separately from an actual waiting time, and is updated whenever a vehicle is added to a line, which should help to prevent this sort of problem from occurring.Edit
: I have now had a chance to add the third feature, so it should also make it into to-morrow's nightly build, although I have not had a chance to test this as extensively as I should have liked.