Andrey, this is the expected behavior. We decided we dont want the view jump around when changes to the scene occur.

Alex, then we need to explain this to Ron, because it looks like this is not the behavior he expects. See related issue 0002752.

I looked at the code and there has never been a dynamic bbox adjustment in slicer4.

It may be a good idea to do it on volume load (or multi-volume load). To do it programmatically one can invoke vtkMRMLViewNode::ResetFocalPointRequestedEvent

Alex, I can add this to my code, but if it makes sense to do it on the volume load, maybe we should do this all the time a volume node is added to the scene, or somewhere in the DICOM module?

I suggest that you add it to your code, there should be no harm in this.
We can do it for load volume later if we decide to.

Seems like we should have a method in the mrml application logic that invokes the ResetFocalPointRequestedEvent on all view nodes in the scene.

This could then be called whenever a displayable node is added to the scene (or possibly whenever a displayable is modified).

Maybe there's a need for a lock option on the viewer.

Since there seems to be no agreement on the exact requirements moving the target release to 4.5

Bill implemented automatic re-centering and it had many side effects so we reverted to the current manual method. Behavior of a fully automatic method is unpredictable when nodes are moved around a lot (especially in IGT) and so many things can alter bounding box of displayable nodes that even observing all those events may have significant performance impact.

However, it could make sense to reset the FOV for example when a volume is propagated to slice views (e.g., when a volume is loaded).