This is a change in behavior with the new navigator, as the new API works with NoteIDs and not position. On one hand it is more reliable, as the position can change in between requests so an expanded/collapsed item can have its state modified, but on the other hand it has a strange behavior with documents that appear several times in the same view, particularly when they appear in the same page.
The reason for this behaviour is that the docs that collapse are all the same doc (0d2a - appearing several times in the same view), and whereas with the old view navigator expand/collapse was driven by View position e.g. 1.1.1 , 1.1.2 etc, it is now driven by note ids. So when you collapse a doc, all instances of that doc now collapse - the Notes client does the same thing.
Basically we have a situation where to overcome performance blockers a new view navigator was created based on new backend functions which return view doc collections based on lists of expanded/collapsed doc ids. In use cases like this (where a given doc appears as a view entry multiple times) there is a consequent change in behaviour. This may be a bit of a problem for existing applications that have such views - ? They can revert to the XPages 85x behaviour and have view navigation driven by view position by using the following XSP property on a per-app or per-platform basis:
But then they cannot leverage the performance gains offered by the new navigator. So it looks like a behaviour/performance trade-off.