Pushed new branch to rMITK MITK: feature/T30253-sam-message-update.

See D884 for fixes.

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

Deleted branch from rMITK MITK: bugfix/T30251-Fix_VS2022_v17.8_warnings_as_errors.

Pushed new branch to rMITK MITK: bugfix/T30251-Fix_VS2022_v17.8_warnings_as_errors.

Deleted branch from rMITK MITK: release/T30248-2023-Week-46.

Pushed new branch to rMITK MITK: release/T30248-2023-Week-46.

I would argue that, while it is an implicit API-change, it works as expected and intended. The commit message contains a rationale. The name is really something that should be the property of the base data rather than the data node, which is dedicated to non-persistent and typically visualization related properties. The most straight-forward solution would be to replace your call of SetName(name) with SetStringProperty("name", name) instead of changing the code of SetName(). By default, this will add the name property to the data node without falling back to a potentially existing base data property. Another solution would be to also listen to the Modified event of the BaseData or its PropertyList or even directly of its name StringProperty.

New checkbox "Allow all models" added to Preferences. Changes included in D875

I would lean to adding a preference "allow unsupported models" (default ==false). If people activate it, they can see all models (that are not blacklisted) and not just the white listed (verified) once.
If the risk is communicated and users are willing to take it, then I would not actively prevent people from using models (as long as they don't crash MITK or so).