Updated task description since the class has been refactored. However, the issue still exists, but now it is - as far as I can see - only abut getting the visibility etc. which can easily be refactored.

I uploaded a fix in D783. Let's see if this will solve the issue also for Ubuntu.

I tested this on Windows with 4974a335ada8a85d7fba8d313e2efc20acc84b48, which was the latest develop I had, since I recently merged something into develop and couldn't reproduce the error.
Used StdMultiWidget, no other plugins open, no data loaded, only the widget planes available in the data storage.
I tested this with the commit given in the task description and couldn't reproduce the error there as well.

With the child task T29335: [Segmentation] Show interactive warning for uninitialized render window geometry being closed, I will close this task as well. If more plugins should be able to enable blocked render windows, this should now be easily doable.

Pushed new branch to rMITK MITK: feature/T28578-Test-MxN-installer.

Deleted branch from rMITK MITK: feature/T29297-Use-selection-widgets-in-render-window-utility.

@s434n I added my draft with a custom multi node selection widget and several action buttons. There are some things missing and going wrong but this should give you a better overview of the current status.
Things that are not working correctly / are missing:

• thumbnail / pixmap for the data node
• currently the widget is not reacting on node changes (name change or later, thumbnail change)
• moving an item in the list does not change the layer order
• currently the length of the list widget / item is defined by the string and thus the push buttons are not aligned
  • also the whole widget is not extended if a name is too long

Pushed new branch to rMITK MITK: feature/T29297-Use-selection-widgets-in-render-window-utility.

Somehow related:

• T24319: Provide filtering techniques for interaction events
• T24274: Globally accesible synchronization handler

Related: T13465: Two 3D RenderWindows at the same time interfere with each other.

I may have found the problem but unfortunately for me that looks like it cannot be easily fixed:
During PlaneGeometryDataVtkMapper3D::ProcessNode, when the plane node to be rendered is processed (called from PlaneGeometryDataVtkMapper3D::GenerateDataForRenderer), imageMapper->Update(planeRenderer) is called. Here the imageMapper is the 2D mapper from the plane node.
Inside ImageVtkMapper2D::Update the mapper is updated by calling ImageVtkMapper2D::GenerateDataForRenderer. This in turn leads to the following line: const PlaneGeometry *worldGeometry = renderer->GetCurrentWorldPlaneGeometry(). I think this is problematic since here the current world plane geometry is used, which is the sliced geometry from the base renderer. However, for the 3D render window the sliced geometry is still either the axial, sagittal or coronal plane. It doesn't matter if we created three different planes from the world time geometry for the base renderer, the world plane geomertry will always be a specific sliced geometry.
Since these steps are performed for all three plane nodes to be rendered, all three plane nodes render the same world plane geometry.

It seems as if there is a general problem with the current crosshair: The crosshair manager provides three planes / plane geometries for each render window such that changing the view direction / anatomical plane will just switch to the corresponding geometry and render the information based on that geometry.
Having done some test with the visiblity of the planes, rendering inside the StdMultiWidget shows that all three planes (axial, sagittal, coronal) of a render window show the same image information / anatomical plane. Changing the view diretion inside the render window will change the anatomical plane, but then all three planes show the same image information of the newly selected anatomical plane.

I managed to fix the rendering of the 3D data even more and now the image information / pixel are shown.
But now the data seems to be inverted on some planes such that the three 2D planes do not match and form a 3D object.

So I fixed part of it by setting a PlaneGeometryDataVtkMapper3D explicitly as done in {D759} for the 2D mapper. Then I was able to immediately set a valid data storage and the crash is fixed.
The three planes are rendered inside the 3D render window but only the frame is visible - no image information / pixel is shown.

So it seems as if the PlaneGeometryDataVtkMapper3D is newly created (automatically) when a render window is changed to a 3D render window (mapper changed to Standard3D).
In that case, the m_DataStorage is empty and the following functions crash (e.g. mitk::DataStorage::SetOfObjects::ConstPointer all = m_DataStorage.Lock()->GetSubset(predicateAllImages);) inside PlaneGeometryDataVtkMapper3D::GenerateDataForRenderer.

I found out that the 3D render window of the StdMultiWidget does not render the data if the widget-plane helper-nodes are removed from the data storage.
If the widget-plane helper-nodes are available but hidden only from the 3D render window (set visibility for that render window to false using properties), the 3D render window does not render the data.
If e.g. one widget-plane helper-node is visible that 2D plane allows to render the data inside the 3D render window, but only the specific 2D plane is visible and not all three view directions.

We discovered that it is currently not possible to use RenderWindowViewDirectionController::SetViewDirectionOfRenderer to change the view direction / rendering of a render window to 3D.
@s434n found out that in order to show the 3D rendering other render windows need to provide the three 2D views for the object in order to have data available to render.