Just for testing purposes: I created an additional Enum value to mitk::RenderingManager::RequestType, called NO_UPDATE. I'm using this new value inside QmitkSegmentationView::CreateNewSegmentation, for the call mitk::RenderingManager::GetInstance()->InitializeViews(referenceImage->GetTimeGeometry(), mitk::RenderingManager::NO_UPDATE, true);.

The result is that the render view is not being reset when a new segmentation node is created (using the "New..."-Button). What happens inside RenderingManager::InitializeViews:

if (((type == REQUEST_UPDATE_ALL) || ((type == REQUEST_UPDATE_2DWINDOWS) && (id == 1)) ||
     ((type == REQUEST_UPDATE_3DWINDOWS) && (id == 2))))
{
  this->InternalViewInitialization(baseRenderer, timeGeometry, boundingBoxInitialized, id);
}

lead to InternalViewInitialization NOT being called (since the new type mitk::RenderingManager::NO_UPDATE does not fulfill the if-condition).

So it seems as if there is already the possibility to separate the geometry resetting and the render view / crosshair resetting. Need to investigate to check different cases and find possible side-effects.

For a more thorough investigation of possible side-effects I will list the occurrences of similar code and see if the mentioned solution could be applied there.
I already started doing that some time ago in T26496: [mxn multi widget] Re-initializations reset all render windows and will continue there:

In T26496, @kalali wrote:

I propose to first gather different actions which lead to an update request.

My conclusion / suggestion so far:

1. RenderingManager::RequestUpdate*-functions add render windows to a list of render windows to be re-rendered, where re-rendering means updating the graphics / pixel (OpenGL)
2. RendereringManager::InitializeView*-functions (changed to RenderWindowManager::InitializeView* in D517) update the Time- / Slice-Navigation controller and the camera controller to a specific view ("field of view").

RequestUpdate*-functions should only be called if the graphics / pixel have been changed.
InitializeView*-functions should probably not be called automatically in most cases, as they reset the user generated "field of view".

What is here still open?

My changes related to this task were mainly to clear some classes and remove uncertainty (see T28617: Inconsistent view initialization in rendering manager).
As far as I see it some changes have been made in the subtask T28490: Segmentation plugin: "new" segmentation should not run reinit! and the respective D523: This was mainly concerned with NOT resetting the view / camera using a newly introduced parameter "resetCamera".

But I think @kislinsk wants to put more "intelligence" into it and separate the re-initialization in some way. Maybe we can discuss this / write down use-cases where we still have unexpected behavior.
I also added subtasks that fit to this task and show the problem of our current reinit implementation.