Can you provide a savegame exhibiting this behaviour?

Went ahead and did it myself anyway. I wonder if this might be pathfinder-caching related...

Here's my reproduction attempt:

Save game: #9609 testing.zip

Wondering if #9554 could have a similar cause.

The relevant pathfinder penalties are: (default values)

• pf.yapf.rail_pbs_signal_back_penalty = 15 * YAPF_TILE_LENGTH (once per signal)
• pf.yapf.rail_station_penalty = 10 * YAPF_TILE_LENGTH (per station tile)

So, currently it will prefer waiting for the reverse-pbs signal, if the station platforms are longer than 1 tile.

I think the problem here is the station penalty:

• The penalty is currently per tile, because this is part of the "pathfinder prefers platform matching train length".
• But this makes no sense, if the train passes through anyway.

So, I think there should be two different station penalties:

• A penalty per station tile, if the train will stop at the station.
• A penalty independent of platform length, if the train will not stop at the station.

Tried the save game with NPF, trains don't use middle track with it.
So with YAPF trains always prefer to use middle track, and with NPF they never want to use it.

To follow on from earlier comments, there are two further YAPF penalties which need to be considered for this type of layout:
rail_pbs_cross_penalty and rail_pbs_station_penalty.

rail_pbs_cross_penalty is the per-tile penalty for a reserved non-station tile.
In many cases the total cost is different depending on how long the train is and how far away it is from the signal it is approaching.
In this type of layout, if you are unlucky you could have different behaviour for short trains blocking the middle track than for long ones.
This defaults to 3 * YAPF_TILE_LENGTH.

rail_pbs_station_penalty is the per-tile for a reserved station tile. As station platforms are always reserved either not at all or in their entirety, the total penalty is proportional to the platform length, and is predictable.
This defaults to 8 * YAPF_TILE_LENGTH.

The problem here is that the cumulative rail_pbs_cross_penalty cost of the occupied centre track is too small to make the centre path more expensive than going via the platform.

I happen to use a similar layout frequently in my own games, except that going via the platforms is the normal path, and the centre track is only used for bypassing trains when the platform is occupied. To make this work the cost of the centre track is artificially made more expensive than the cost via the platform but less expensive than the cost via the platform when occupied.

So, I think there should be two different station penalties

The trouble with this is that it makes the track cost a function of the instantaneous state of the vehicle which is problematic for the segment cost caching which is used outside of the signal look-ahead distance.
You could do this only inside the signal look-ahead distance but this creates the risk of inconsistent pathfinding.

You could do this only inside the signal look-ahead distance but this creates the risk of inconsistent pathfinding.

I don't quite see the problem with this. By the time you arrive at the station from outside the lookahead distance, the situation probably changed anyway.

Maybe unrelated, but is it supposed to work? Why train 11 not picking marked route? It stick with route occupied by train 12.

#10804 Should fix this. The impatience value would rise until a train takes a route through a station.

I just bumped into similar (same) issue - on a high-throughput loading bay trains sometimes stop while there are still empty tracks available. If it is the same, then it is happening with long (7-tile) trains. I haven't looked at implementation but hope that the fix will address long trains as well.

https://gaming.stackexchange.com/questions/404258/debugging-high-throughput-station-why-does-a-train-stop-when-there-is-a-path

(have a save at exactly this moment as well)