In a certain sense, the bug would be fixed by making sure the menus are present when the layout changes.
However, it might make sense to rethink the usefulness of these menus in the MxN context, since many features are not usable anyway (e.g. rotation).
The layout management of the rightmost menu can still be used, but might need heavy extension for useful usage. We might redesign it entirely, to make it more general for Std- and MxN-view, or remove it from MxN on purpose.

Yes, this still happens as described above.

Deleted branch from rMITK MITK: feature/T29273-Decouple-TimeNavigationController-from-SliceNavigationController.

Discussion result:
Simplify bounding box interaction / Add simpler version and make it available outside of the Image Cropper

The action makes sense, for the stamping widget we'll have to check if it is used somewhere, and in doubt remove it.

Discussion result: remove

Discussion result: for now, we can live with this being a known issue

I am also in favor of option 3.

Conclusion: still needs subtasks

• can the binary tag be removed?
• convert binary images easier into segmentations
• offer python utility package as a way to convert -> T29389

Conclusion: makes sense to do, will be tackled implicitly in the future.

Discussion: the listed parts can be removed + semantic relations can also be removed (in its current implementation state, because it would need to be reimplemented with property relation rules).

Has been clarified

Conclusion: In general it makes sense, but we would want to get rid of the "locked state" of the perspective. Needs further research if the locked state can be removed easily or be made more clearly visible, e.g. by a UI element.

MITK Workbench XL
MITK Workbench - extra

I don't see a good way to handle this differently. Discerning if a slice has become obsolete would be very hard, especially since it's in 3D and the slice could be intersected by a segmented slice of a different orientation. The position node remaining does not seem like a problem to me, so I would vote to close as Invalid or Wontfix.

Can reproduce. I agree with your explanation. When group 1 is empty, it can't actually be selected. There's the dotted line, but group 2 is still in focus (which is stated in the popup dialog). I guess after group 2 is deleted the "focus" is not set correctly.
I guess we could either ensure that the next available label is automatically selected, since usually there is always a label selected, or the "Delete group" should be respective to the dotted-line selection of a group.
I'm not sure if this contradicts previous discussions we had about the topic, but I would actually prefer the second option. Generally, it feels weird that one is able to kind of select a group and interact with its context menu, but the buttons above still refer to the group of the focused label. For example, it is impossible to add a label to an empty group with the buttons (except for the first one).