OpenTTD

No it's not; the authorities only pay for passengers that have the city as final destination.
People passing through are not paid for (neither for people that pass through while staying in a train, nor for people that have to switch trains).

The fact that they have to switch trains is basically a property of your train network, not something that the town authorities control or want.

If I want subsidy I must isolate stations. It is against cargo destination. Ok, how to get subsidies?

A solution could be to priorize subsidized lines against others in DemandHandler and McfFirstPass. This, however, would somewhat defeat the purpose of subsidies. While the line is subsidized traffic on that line would be artificially increased. As soon as it's not subsidized anymore traffic would drop again, in extreme cases as the one shown above, to 0. Whoever gives the subsidy should feel cheated then.

Or we could pay the bonus (but not the original delivery income) if the cargo is only transferred, not actually delivered. That might work. The problem with the above savegame is not that there are no passengers travelling along that line. The problem is that only a very small fraction of them are delivered to the subsidized destination.

However, paying the subsidy on transfer has two problems:
1. Cargo could stay in the vehicle and not be transferred at all. Then it should still be subsidized.
2. Cargo could first be transferred and then delivered to the same town. It would get two subsidies.

Maybe we need a "subsidized" flag in CargoPacket which would be set whenever the packet travels along a subsidized route and which would trigger the extra payment at the final delivery.

On the other hand, maybe we want to scrap subsidies altogether and make people use GameScripts instead. I guess something similar to subsidies can be implemented as GameScript already.

There isn't really a safe way to priorize links in the link graph. As soon as you have multiple subsidies involving the same towns or industries you'll get the same problem again. All of them would then be priorized and steal cargo from each other. As no one seems to like the idea of paying the subsidy not only on deliver but also on transfer or passing through the only sane thing to do may be disabling subsidies for automatically distributed cargo.

What problem is about transfer?

This is solution for transfer subidies. Look at the image.

ABC - real way of train for AC
AC - computed way of train for AC
AC2 - computed profit for subsidy AB
AB2 - vector for compute subsidy transfer profit for AC (rotation angle is angle between AB and AC)

I don't really get that picture. The root cause of the issue is that cargodist routes cargo independently of subsidies. So if you build a route suitable to fulfill a subsidy offer, cargodist might not send any cargo along that route which means you don't get the subsidy. In your case cargodist does send some cargo along that route, but that cargo only passes through and isn't delivered at the subsidized destination which also means you don't get the subsidy. That letter problem could be solved by granting the subsidy not only for delivered cargo, but also for cargo passing through. However, as that significantly changes the semantics of subsidies, people might not like it. It's less controversial to just switch subsidies off for automatically distributed cargo as cargodist is a new feature we can easily change without making anyone angry.

Ok.

Regarding subsidies and Game Scripts: GS can announce extra subsidies to players (by telling OpenTTD the source + dest) but they can currently not disable the default subsidies created by OpenTTD. It has been suggested that the default subsidies in OpenTTD could be converted to a default GS that is used when no custom GS is selected. This however do not cover detecting when a subsidy should be awarded nor bonus payment.

Just preventing the default subsidies from spawning for automatically distributed cargo is easy. See https://github.com/ulfhermann/openttd/commit/9baa232beebeebf159b8f36d0259edf566669a47 . however, considering how hackish that piece of code already is, it might be better to redesign the subsidies after all.