question

This was initially logged as a bug, but looking at it now, this is by design. It's just a side effect of the way that you have set up the model. You have defined the spur path as using accumulation. When a path uses accumulation, it must define an ordering of AGVs on that path, so that it knows which AGVs are 'behind' which other AGVs. This includes the AGVs that are set to be on the path when the model is reset. If you were to set the two AGVs' reset control points as different control points on that spur, then it would be clear that one will be blocked in trying to get out of the spur if there is another idle AGV in front of it. However, you have set both AGVs' reset control points as the same control point. Here the AGV system must still set a defined ordering of one AGV in front of another, because it is an accumulating path. But since they are both reset to the same control point, it just sets the ordering arbitrarily. In this case the ordering is based on the primary direction of the path, but I imagine it's also dependent on the member-ranking of the AGVs (disconnect the two AGVs and then reconnect them in different orders and the behavior will likely change).

If you want it to behave properly, then you need to make your intentions unambiguous. Either have the AGVs reset to different control points on the accumulating spur, or make the spur not accumulating. In general it's not a good idea to have spur paths be accumulating anyway, because they are two-way paths and will almost always cause issues with accumulation.

There is a general warning in the user manual about not over-using accumulation:

Troubleshooting AGVs

I will make an additional note that says that generally you should not use accumulation for two-way paths or spur paths.