This is probably where things get a little controversial.
There are some song select flows wherein song select just wants to
ensure sanity by authoritatively setting the global beatmap. The goal is
to change the beatmap immediately and instantly. Therefore it should
kind of be the carousel's job to figure out its grouping complications.
To that end, `CurrentSelection` is made virtual, and overridden in
`BeatmapCarousel` to perform a sort of reconciliation logic. If an
external component sets `CurrentSelection` to a `BeatmapInfo`, one of
the two following things happen:
- Nothing, if the current `GroupedBeatmap` is already a copy of the
beatmap that needs to be selected, or
- The carousel looks at its items, finds any first copy which matches
the beatmap that the external consumer wanted selected, and changes
selection to that instead.
Because of this it was possible for a scroll to not be able to scroll
to the panel it wanted to scroll to because its layout height was
too small for the target Y position of the panel that it wanted to
scroll to.
The scroll height was set in `updateDisplayedRange()` which is notably
after attempting to scroll to the current selection.
I'm having trouble finding a repro for this, but I know it's been an
ongoing issue. I've had this patch applied locally for a while now and
haven't run into a failed scroll to selection with it.