CollectionView is expecting to find allowsMultipleSelection set on the content object (which assumes that SelectionSupport is mixed in) rather then as a property on the CollectionView itself.
However ColectionView ignores the allowsEmptySelection property from the SelectionSupport mixin. This feature is available by setting the completely undocumented allowDeselectAll property on the CollectionView.
This API should be cleaned up so that for collections where you can select 0 or more items, you do not have to define one property on the content object/controller and the other on the CollectionView.
I'm just going through old tickets attempting to clear out the large backlog.
There is definitely an inconsistency here, but I'm not sure what the solution is yet. If you bind up the selection to an object that has SelectionSupport (like ArrayController), then the selection is prevented from being incorrect by the configuration of that object. If you used a delegate, you could control the behaviour also. However, the way that CollectionView determines this is weird as you noted above.
I'm going to see if I can't just mix SelectionSupport into CollectionView and simplify it and SC.CollectionViewDelegate at the same time, so that the result would be that you could set allowsMultipleSelection & allowsEmptySelection on the view or on the content/delegate.
In theory, each object should be deciding for itself what kind of selection it supports, with some kind of lowest common denominator settled on in bound situation. Maybe SelectionSupport can actively enforce its flags by turning selection into a read/write calculated property? Then mix it into both sides. That should just magically work.