This would be a very helpful feature IMO.

For distribution, round-robin would be preferable. Random distribution should come out even statistically over large datasets, but might cause unexpected localised behaviour, which will cause bug reports and be hard to debug. Round-robin is easier to understand.
https://en.wikipedia.org/wiki/Round-robin_scheduling

Also are you aware that the newgrf spec supports industries stopping and starting cargo acceptance, both for the industry, and for industry tiles? This creates some tricky cases. This can be tested with Pikka's Basic Industries grf, which limits acceptance at secondary industries.

This seems like a reasonable idea. This seems like a fundamental economy change, so I wonder if it warrants a configuration option? Don't add this now, I just wonder how others feel.

This seems like a fundamental economy change, so I wonder if it warrants a configuration option?

Presumably it changes the behaviour of existing savegames significantly, so maybe we have to preserve the old behaviour at minimum?

Pretty sure this is not a "Change". Possibly even a "Feature? :)

I think this risks making competition in multiplayer games more bland.

Consider for example the situation where three companies each have a station by the same industry. The stations have ratings of 80%, 78%, and 76% respectively. With this patch, all three companies will get almost equal amounts, giving much very little incitement to the 76% company to try to do better.
By the original rules, the 76% company would be forced to make a much better service to even get any cargo at all, since only the top two stations get any cargo.

Introduce a fourth station with rating 38% (half of 76%) and it would receive half the cargo of the 76% station, despite being much, much worse.

One solution to this may be to use the ratio of the square of the ratings (each rating multiplied by itself), instead of the ratings straight.

You can make the distribution difference even more extreme by using higher powers than 2.

Another option to possibly add in the mix is to take e.g. the bottom third of all stations out of the running. Or stations whose rating is less than two thirds of the best rating.

@nielsmh Your approach also changes the amounts for when there's only 2 stations. My approach still does the same as master if there's only 2 stations.

Tests:

      squared rating   |  rating sum
      -----------------+------------
      29%, 13 ( 9.77%) | 17 (12.88%)
      29%, 13 ( 9.77%) | 17 (12.88%)
      30%, 14 (10.53%) | 18 (13.64%)
      33%, 17 (12.78%) | 20 (15.16%)
      48%, 35 (26.32%) | 29 (21.97%)
      52%, 41 (30.83%) | 31 (23.48%)

More tests:

3 stations: https://paste.openttdcoop.org/po46thby7

         47% rating / 72% rating / 83% rating
Samu:    642 (23%)  /  991 (36%) / 1136 (41%)
nielsm:  426 (15%)  / 1012 (37%) / 1331 (48%)
Master:    0 ( 0%)  / 1290 (47%) / 1479 (53%)

2 stations: https://paste.openttdcoop.org/pnp04lwfn

         33% rating / 83% rating
Samu:    664 (28%)  / 1679 (72%)
nielsm:  317 (14%)  / 2026 (86%)
Master:  664 (28%)  / 1679 (72%)

I have a dilema:

<Samu> why include an industry to the list if it receives 0?
<planetmaker> it might get something later?
<peter1138> Samu, prove to me that it can receive 0 at that point.
<Samu> incoming_cargo_waiting could be a stockpile
<nielsm> peter1138, I think it can reach that line even if ind->incoming_cargo_waiting[cargo_index] == 0xFFFF
<nielsm> so the second arg to min would become zero
<peter1138> Okay.
<nielsm> question is, should be industry count as having received a delivery (of zero) if its stockpile is full?
<peter1138> And the problem is it will trigger production when it should not have done.
<peter1138> nielsm, probably not.
<peter1138> Samu, i guess this is just a case of explaining the problem clearly 

This PR changed it to not count as having received a delivery of zero. Otherwise, it would be added to both rejected and _cargo_delivery_destinations lists, which wouldn't look right.

Without this being an option, I do not see how this is going to work. And if we do this, we should allow control via either GS or NewGRF, instead of hardcoding yet-another-way-of-doing-this.

So I do not think this is the correct solution for the problem. Just changing the current way of doing because it flavours you only means others won't like it, and we will have PRs ping-ponging solutions all day. We need a more constructive solution to this problem.

Tnx for the contribution though!