Yes. Seems a bug.
Changing just the end lines of this function

Track NPFShipChooseTrack(const Ship *v, TileIndex tile, DiagDirection enterdir, TrackBits tracks, bool &path_found)
{
	...

	if (ftd.best_trackdir == INVALID_TRACKDIR) {
		/* We are already at our target. Just do something
		 * @todo maybe display error?
		 * @todo: go straight ahead if possible? */
		path_found = true;
		return FindFirstTrack(tracks);
	}

	/* If ftd.best_bird_dist is 0, we found our target and ftd.best_trackdir contains
	 * the direction we need to take to get there, if ftd.best_bird_dist is not 0,
	 * we did not find our target, but ftd.best_trackdir contains the direction leading
	 * to the tile closest to our target. */
	path_found = (ftd.best_bird_dist == 0);
	/* Discard enterdir information, making it a normal track */
	return TrackdirToTrack(ftd.best_trackdir);
}

Solves the problem.
But this is not how it is supposed to work. I will look further, as NPF should ignore first tile, and it is not ignoring it.

Okay, but why does it need to pathfind to reach the tile its already at?

Or do you mean it refuses to pathfind through the vehicle's current tile? If so, what is wrong with turning around?

Okay, but why does it need to pathfind to reach the tile its already at?

Because it is leaving the tile and needs to find a path back.

Or do you mean it refuses to pathfind through the vehicle's current tile?

Yes. NPF fails if destination tile is origin tile at the moment. It returns INVALID_TRACKDIR. I am looking into it. I have a branch here (6 commits), but I still have to investigate whether this works and doesn't cause new problems.

If so, what is wrong with turning around?

What is wrong in choosing a track on next tile? Are all-of-a-sudden-180º-turns better?

I don't know, I'm just asking questions to work out what the actual problem is!

I don't know either. Maybe just reversing is ok, but other pathfinders go ahead. I don't think reversing is ok in this situation, but I am not sure about it.