During a merge view it is possible to install cache views with less members if one of the sub groups has a higher topology id than others.

This is because of https://issues.redhat.com/browse/ISPN-8962. It was originally intended to prevent too large of clusters where a sub group may have been delayed due to GC or similar. But also has the unintended side effect that if you have a split brain and a sub group within that split brain progresses much further in topology ids than others. In that case the "merge" cache view may only be one of the sub groups.

A more concrete example is you may have 4 members in a cluster. If due to network issues or CPU bound issues they split into sub groups of [1,2,3] with a topoloyId of 34, [3,4] with a topoogyId of 38 and a merge view of [1,2,3,4] with a topologyId of 35. During that case the [3,4] cache topology view could be 3 topology updates further along the either of the other two and installed as the winning topology. Unfortunately, that means the cache topology id would be stuck at [3,4] despite the actual cluster being [1,2,3,4] unless we have more changes in the cluster to update this.