I tried to find a solution. The problem is the same problem we had with other segmentation operations:
mitk::SegTool2D::GetAffectedImageSliceAs2DImage is called with a reference image (the segmentation) and a timestep although the segmentation is static and the timestep != 0 does not exist.
So obviously one would need to translate a timepoint into the timestep of the static segmentation. But I don't see a way to access the current timepoint and also the whole 2D fast marching is totally unclear to me.
mitk::FastMarchingTool already holds the current timestep, which is changed by listening to the image navigator. But the timestep does not help us here.

Maybe it's possible to change

Image::Pointer workingImage = dynamic_cast<Image*>(this->m_ToolManager->GetWorkingData(0)->GetData());
workingImageSlice = GetAffectedImageSliceAs2DImage(m_WorkingPlane, workingImage, m_CurrentTimeStep);

into something like

Image::Pointer workingImage = dynamic_cast<Image*>(this->m_ToolManager->GetWorkingData(0)->GetData());

TimePointType referenceImageTimePoint = m_ReferenceImage->GetTimeGeometry()->TimeStepToTimePoint(m_CurrentTimeStep);
TimeStepType workingImageTimeStep = workingImage->GetTimeGeometry()->TimePointToTimeStep(referenceImageTimePoint);

workingImageSlice = GetAffectedImageSliceAs2DImage(m_WorkingPlane, workingImage, workingImageTimeStep);

inside mitk::FastMarchingTool::ConfirmSegmentation() but I don't know if this is the best option.

I just found out that the same code (mitk::SegTool2D::GetAffectedImageSliceAs2DImage) is used when using e.g. the simple add-tool. However, here unsigned int timeStep = positionEvent->GetSender()->GetTimeStep(image); returns 0 as timestep, although the timestep was set to something != 0 in the image navigator. This works, because mitk::BaseRenderer::GetTimeStep already transforms the current timepoint with data->GetTimeGeometry()->TimePointToTimeStep(GetTime());.

This means that the problem probably lies directly inside mitk::FastMarchingTool::ConfirmSegmentation() (see last comment) where the m_CurrentTimeStep is used instead of the transformed timepoint.

The same problem exists in T27800: [Segmentation] Live Wire crashes with 4D image and static segmentation: Here, mitk::SegTool2D::GetAffectedImageSliceAs2DImageis called with a reference image (the segmentation) inside mitk::LiveWireTool2D::ConfirmSegmentation() with t != 0.

In T27800#211261, @kalali wrote:

2. There is a basic flaw in the design which should be discussed instead of just fixing the symptoms with the suggested fix

You are right. I have looked into the Tool2D code base. And I think the only proper solution is to make an complete overhaul and refactoring like I did for the AutoTools (3D). Meaning to check all implicit or explicite usages of time(points) and also clean up and generalize code, as also several 2D tools do a lot of same stuff but just a little bit different, may be due to different developers. But thats not good for maintenance an so on...

I havent looked at the fix. But I tend to just deactivate all tool for 4D images, if they currently do not work for 4D. And then make a real complete overhaul... Lets discuss that.

I landed the changes of D423. For the next steps, consider T27507#211912.