I made a mistake with nodetype constraints config this week, on my local env there was no issue, but on the live site I had a node structure I didn’t think of which was allowed by nodetype constraints, but by changing the nodetype constraints it was no longer allowed…
Just for the example, imagine the nodetypes ‘Chapter’ and ‘Subchapter’. Before my config change ‘Chapters’ were allowed to be nested, after my change a ‘Chapter’ could no be a child of another chapter, but shortcuts, pages subchapters were allowed.
The problem that now occurs is that Neos hides the disallowed nodetypes in the ‘node type’ selectfield in the inspector. As a result the first value in the selectbox becomes selected, which is effectively a change to be applied. So an editor is basically tricked into changing the nodetype and it’s easy not to notice the green border in the inspector as it might be on a tab which is not opened.
This is not such an issue if the new nodetype has the same childnodes, but my case the shortcut was the top item 
Meaning the published change lead to a loss of content.
Luckely I could restore the data, so nothing lost. But conceptually it might be good to think about how this field should behave. Maybe Neos should warn that the value in the nodetype selectbox is not allowed by constraints, and adds some kind of “wizard” for the editor to make a choice about what nodetype to switch to? Or should the nodetype switching still have the value for the current nodetype even if it is not allowed by constraints?