(Please disregard if upstream has made major recent changes to how TRANSPORT_EMBARK is executed, and accept my apologies.)
To recreate the issue, set a req that ACTION_TRANSPORT_BOARD requires the unit to have moves_left, then take a unit with <1 moves_left and embark to adjacent tile.
If land unit embarking to water, it will move to the water tile but then be unable to embark because ACTION_TRANSPORT_EMBARK is a pseudo-action that really does a dual action of order_move then order_board. So it will be left drowning in the water. But in all cases it will move to the tile but then not board.
The bugged code also assumed order_board will always be legal on the transport's tile in all cases where embark was legal from the adjacent tile (conceivably not the case in some theoretic rulesets.)
Theoretic ruleset example: you need to be on a special space-dock infra tile to embark on a spaceship, but the spaceship is only pulled along-side this orbital docking satellite.)
At FCW, transport embark ultimately calls unit_move with emark_to punit pointer parameter, then ultimately arrives at a line of code like
if (ptransporter) {
Changing FALSE to TRUE changes the bool parameter 'force' to enact the boarding no matter what, and this fixed the bug for us at FCW. To me this made sense because once the unit moves to the transport's tile, it represents a "promise" that is executing the order TRANSPORT_EMBARK which was already legally represented to the user as a valid action they could do with the DO-click-tile popup menu.
lexxie9952 
(Please disregard if upstream has made major recent changes to how TRANSPORT_EMBARK is executed, and accept my apologies.)
To recreate the issue, set a req that ACTION_TRANSPORT_BOARD requires the unit to have moves_left, then take a unit with <1 moves_left and embark to adjacent tile.
If land unit embarking to water, it will move to the water tile but then be unable to embark because ACTION_TRANSPORT_EMBARK is a pseudo-action that really does a dual action of order_move then order_board. So it will be left drowning in the water. But in all cases it will move to the tile but then not board.
The bugged code also assumed order_board will always be legal on the transport's tile in all cases where embark was legal from the adjacent tile (conceivably not the case in some theoretic rulesets.) Theoretic ruleset example: you need to be on a special space-dock infra tile to embark on a spaceship, but the spaceship is only pulled along-side this orbital docking satellite.)
At FCW, transport embark ultimately calls unit_move with emark_to punit pointer parameter, then ultimately arrives at a line of code like if (ptransporter) {
Changing FALSE to TRUE changes the bool parameter 'force' to enact the boarding no matter what, and this fixed the bug for us at FCW. To me this made sense because once the unit moves to the transport's tile, it represents a "promise" that is executing the order TRANSPORT_EMBARK which was already legally represented to the user as a valid action they could do with the DO-click-tile popup menu.