[Buschel]

For example I really do not understand what the change of sort search results by ascending label is supposed to do.

Thanks for pointing this out. Will be giving some details. First, the related PR has screenshots and more background: https://github.com/xbmc/Official-Kodi-Re.../pull/1153
But let me also spend a few words here. The search until now just filtered the list as it came from Kodi, it did not apply any sort of any kind. In "Top 100 Songs" Kodi will respond with a list of songs, sorted by their playcount. In "All Songs" the sorting done by Kodi is something I never understood. When you searched in such a list the order was kept, but only the items with matching search criteria were kept in the list. So, the underlying sort order was kept. For most of the menus the default is anyway sorted by name/label, you should not see any difference.
The point @UlfSchmidt made is valid, I think. If you anyway search for a name of a list item, it makes sense to sort the results by name as well.

1) The section headers are causing what I presume to be cell re-use as you call it. ...

Oops, never saw this. That's why TF builds are great for testing. Yes, looks like a cell re-use problem. This is most likely not a regression, but maybe got a higher probability to show up. I recently had fixed (1152 in review) another cell re-use issue for GlobalSearch which never got reported. GlobalSearch lists are a bit special as they mix all kind of different layouts. Will review this again.

2) Section headers while search is active don’t float at the top under the search bar like they do outside of a search. This to me is a lost opportunity.

Good point. Not sure, if this works with the additional "x Results" on top, but I will try.

3) ... If I search “1985” and get maybe 50 items returned. Then scroll to bottom of search results. Then clear search. Now scroll to the top. I get massive stuttering.

No idea, I will try it on my devices. But I have few hope.

Impressive you decided to tackle refactoring the class when it was very clear you did not want to take that on at the moment. Major kudos. 👍🏻

Future will let me regret this. 😉 Known glitches will be replaced by a new implementation with unknown issues.

The basics work quite nicely now. But I already saw a glitch I need to understand better, and there is a catch I was not taking into account which impacts the usability (you prefer let the view snap into a left position when moving the pane left, and vice versa) in the reworked implementation. And this will require some special case handling -- I hope not to the extent which was coded before.

Let me spend some time on this, I have few days vacation now.