This issue is not entirely clear cut. Firstly, from a techincal perspective, it is not entirely easy to set up a weighted average speed: currently, average speed is stored as part of the "financial history" set for the convoy (meaning that it shows on the graphs in the convoy's information window). The average speed stored is a sum of all the average speeds recorded in the last month, plus a separate variable storing the number of trips in the last month. The display is then given by dividing the sum of the speeds by the number of trips. This enables the graph to be updated instantly whenever the average speed is changed.
Secondly, the reason for having average speed in the first place is to measure trip speed. People might take trips from A to C, from C to B, from A to B, from B to A or from C to A. Each of those passengers care about their speed, and, to the extent to which they care about their speed less the shorter the journey, that is already accounted for in the revenue calculation, so adding it here would be double counting, and make convoys that have a local stopping section (remember, the declaration time to stop at each stop substantially reduces the speed) and a fast section appear faster than they are for all but trips involving the long-distance part of their run. The passengers taking the convoy between any pair of stops in the local stopping section would get a service far slower than the average would then indicate. Thus, weighting it by distance does not necessarily produce a correct result, since the passengers taking shorter trips are uninterested in the distance that the convoy travels overall.
