This is annoying because the first movement step on deployment of troops from APC/chinook/water-transport (#2016) and infantry production looks ugly. Don't know how to fix this and why the drag command is even necessary as walking to rally points cares for subcells (uses Mobile.MoveTo).
The idea behind Drag was to have a simple visual-only activity for moving an actor from an arbitrarily pixel position exit, which is determined by the artwork, to the "exit cell" where it physically enters the world. From there, the actor moves using standard methods to the rally point. This works fine for production exits, where all units follow the same exit path and leave the exit cell to go to the rally point, but not for transports. It should be simple to modify the exit code to give Drag the subcell px position, but you will need to be careful to not visually regress production exits.
This even looks bad on production exits if the rally points are blocked because they will stack on top just like leaving transports.
I see. I suspect you'll want subcell-aware units to move to the middle of the exit cell (as they currently do), and then immediately into a different subcell. Production and transport exit should halt once there are no free subcells, unless this has regressed since I left. This could be implemented by queuing a "change subcell" activity after the drag.
They will halt in the center of current current subcell if they can't move because the rallypoint is blocked so even this workaround looks awful. I tried to fix this many times now, but I don't understand subPxPosition/subCell movement at all which results in even more horrible glitches I have to stash away again.
Closing as invalid - its the job of the thing calling Drag to specify the appropriate start and end coordinates.
We should open a new bug covering the production / transports exits specifically.
This is fixed by #6208.