The proposed solution for #17518 (#57707) included an implementation of the snap animation that was too specific to the use case of the NestedScrollView.

Instead, floating support will be enabled in #59187 without support for snapping simultaneously. This is documented in that change as a known limitation.

The challenge of the snapping animation is caused by a couple of different factors:

• the RenderFloatingPersistentHeader lays out by keeping track of a mock scroll offset, _effectiveScrollOffset, in the outer scrollable. This is not accurate or easy to reconcile with the inner scrollable position.
• The snapping animation animates this _effectiveScrollOffset
• Support Floating+ SliverAppBars in NestedScrollViews #57707 proposed animating the position of the outer scroll view by setting the pixels, as using animateTo will actually result in an infinite loop, since the animation is triggered by the scroll notification
• During the layout path of the RenderFloatingPersistentHeader, the _effectiveScrollOffset is clamped to be within the current scroll offset of the outer scrollable, again complicating any additional inner offset we may care about
• The NestedScrollView can at any given time dispose of the inner position, or have more than one position attached to the inner scroll controller

There is further discussion in the linked issues/PRs.

Beyond the implementation in #57707, we also tried passing the inner position information to the outer through the NestedScrollView.headerSliverBuilder, and from there on to the SliverAppBar. This seemed even less generic than the modified animation in #57707, and was never successful because of the precarious nature of the inner position(s) of the NestedScrollView described above.