@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.

Should be tackled as soon as T29206: [SEG] Implement a Qt model for LabelSets for MVC patterns is done.

Adding a data node reset-geometry-action was a first step and enough to tackle this issue. If there are more requirements for some "intelligence", new tasks need to be opened.

Render window specific visibility has to be covered, as mentioned in D756#26848. This will be done in T29403: [mxn multi widget] Concept for crosshair data type.

This task is invalid; related work will be continued in T29297: [mxn multi widget] Optimize data accessibility inside render windows.

This is also related to T29381: Move Multilabel classes to Core module.

consider rMITKa73e482c0387: moved labelset-related classes out from core