As seen in the Microsoft Groove App in Windows 10:

I would be happy to help implementing it if someone can outline how it can be done.
Not sure, but maybe this can be a base to start off? https://github.com/JustinXinLiu/StickyHeader_WindowsComposition
Many thanks for the pointer. Very interesting but the sample works directly with the ScrollViewer, the Header is also directly part of the ScrollViewer content. That make me worry if this aproach allows to keep ListView virtualization working.
I am experimenting with an approach now that uses a Grid with the Header and the ListView in the same cell where scroll offsets and heights are adjusted in the ViewChanged event of the ListView ScrollViewer. It is pretty close but not exactly like the screenshot above now.
Using the Composition API to achieve this shouldn't mess with virtualization, even if it works directly with the ScrollViewer. Additionally if this is done entirely through the Composition API with the use of the Expression system, you'll get better performance than by listening to events. If done this way, everything is handled in the system compositor and thus can be done on the same frame as the manipulation.
I experimented with a simple ListView and a Header and was able to make it sticky very much like in the StickyHeader example. Almost there.
The header is now animating correctly, two issues left:

If someone wants to take a look, here is my test project: https://github.com/pdehne/QuickReturnHeaderListView
If possible I would like to avoid list view proliferation. Could it an additional control working with a regular list view?
The test project is only a proof of concept so far that is almost working. For wrapping it into a proper control I was thinking about moving the code in MainFrame that setups and drives the animation into the subclass of ListView that should be renamed from MyListView to something like QuickReturnHeaderListView or just QuickReturnListView. Are you suggesting I should try not to subclass from ListView? Maybe use a UserControl? No problem, I am open to provide the functionality in any way you like, just let me know how.
My concern is that we will end up with 10 different listview based controls where I think we could provide controls or attached property that change current listview
More in this thread: https://github.com/Microsoft/UWPCommunityToolkit/issues/186
In your case, I would love to have this kind of construct:
Does it make sense?
Just for reference, this code was not showing in your comment, got it from the comment notification mail:
<QuickReturnHeader TargetListView={Binding ElementName=MyListView} />
Sure, I think it would make a lot of sense to add these kind of features in a way that may allow multiple features to be merged into the standard ListView.
Hopefully someone can help with the ZIndex problem. Once this is fixed I'll try to wrap it into a construct like the one you showed.
If I use the Live Visual Tree in Visual Studio to set the ZIndex of the marked ContentControl to 1 the header is stacked correctly above the list view items:

Does anybody know how to do this in code?
Got it working now. The solution was to decrease the ZIndex of the ItemsStackPanel.

Trying to refactor this into a mix in class as suggested by @deltakosh now. Updated the GitHub project too if someone wants to take a look.
Closing this one for now. Please open a new one if the (really tiny) lag is a problem