Project Search limitations (eg, identifying location of several hit items)

[dbc183c7]

I have the Binder set to open things in the left-editor, which editor opens to the right editor.

I do a Project Search, which yields EG three items found.
I click on a found item in the search results list, which opens the item in the left editor, or key Ctrl + Alt + Enter, which opens the document in the right editor.

The Shift + Alt + left arrow does not work in either document-displaying editor.

While this non-behavior may be understandable, even expected during a Project Search, it is a disappointment to me because using Shift + Alt + left… would have been a way for me to tell in which container(s) the found document(s) was …
without having to Ctrl + Shift + 8, then retype/paste the Project Search string to continue my perusal (in lieu of the Project Search display’s lack of a hits road map (tree?)).

Actually, Shift + Alt + left… does not appear to work in any case in the right editor—except that the Inspector view does change to the container’s info!? And does change the left editor to the right editor’s document’s container … .
(All along, the cursor is blinking in the right editor and any typing updates that editor.)

Does View > Go To > Editor Selection Alt+Shift+Right 'mean' Ctrl+Shift+Right?

[dbc183c7]

Relatedly:

It would be nice to be able to sort Search Results (without disturbing the actual locations of the found items), in my case in order to find duplicate (at least in name) documents.

(The sort-results displayed either in the Results list itself or in a selected-finds outliner editor.)

In the header bar of an outlining editor, it would be useful to see the tree/level path for the instant folder/container
—Eg, Works > Book > Part > Chapter > Section—
Displayed similarly as the hover pop-up addresses for Inspector links and in the app window’s title bar (the latter which I do not use).

Speaking to the repeated "Ctrl + Shift + 8" execution noted earlier: As an interim measure to see a found item's location and avoid the "search, then …+8" repetition, … it would be nice were a hover pop-up also possible for found items in the search results?

(This would remove the steps needed to Ctrl+Shift+8 for each search-found hit item, often followed by a re-search.)

[dbc183c7]

Thinking less about Project Search 'limitations’, more about further integration ... . I would find it of use were there a RC context menu choice that would allow me to 'find throughout’ the project all the items with the same name as the selected item in the Binder or outlining/card Editor.

And similarly in a text/card Editor, a Project Search context menu item for selected words or phrases?
I can almost accomplish the same thing, selecting the word/phrase, then dragging it to the Project Search box. However, as there is often already a 'string' in the box, click-drag-drop pre/ap -pends/inserts the new string to the old: Perhaps this could change?
Perhaps a swipe of the insertion point across the old text could highlight it (or a part of it) and past the new string over it?

(As with some of my post questions, I need to keep it in mind that Scrivener's target audience and purpose are writers and their work. It is not the more PIM orientation of my prior software.)