When moving to the “next [previous] document”, either by UI click or (Windows) Alt-Shift Down [Up] Arrows, the affected editor does not retain focus, this leads to additional & unnecessary actions to give focus back to the editor in order to e.g. page down.
Could you enhance it so that focus is retained when performing Go To Next/Previous document?
I agree.
Especially since (I just tested it) the focus seems to be nowhere at all after. (Meaning: there is no advantage whatsoever that one could pull out of it, as it currently is.)
There is a huge ticket on this, as it goes into a lot of different places where you might not first think to do, like whether you should be able to continue typing in a custom metadata text field when flipping through a series of items (the answer is yes). And it’s not just Next/Prev, but history, navigate to enclosing group, quick search results, what happens after you press Ctrl+N… you can imagine the permutations if all of this has to be handled individually.
I agree though, it is quite vexing to have to do so much focus shortcut usage whenever moving around.
Oh… (!) …the nightmare. (Yes, I can imagine.)
In fairness I also expected something (perfectly reasonable) like that 
and the view from out here is no doubt partial.
That said, it currently seems inconsistent insofar as metadata field focus remains (I checked) on next/previous, but focus in an editor is removed. Why? What purpose does that serve?
Surely the obvious starting point would be: focus stays where it is – in a metadata field, in an editor, etc. because the alternative of “everything is different” and no focus at all means nothing is right, isn’t it?
The solution seems obvious (caveat coder): much like “show invisibles” as a toolbar item would be a toggle to
NB I also checked backward in document history, because that was specifically mentioned, and that removes focus too even from metadata editing (unlike next/previous)
The more I examine the current approach, the weaker the argument against retaining focus seems to become, because, whilst next/previous retains e.g. focus in metadata, ctrl=] etc. removes that too, so “changing documents” has no consistency at all, AFAICT.
“Navigate to enclosing group” is not available if the focus is in a metadata field, so I’m not sure how that factors in - in theory it seems inconsistent with the next/previous and document history in this respect.
Colour me confused 
PS I think I mean: focus should remain where it is unless the “go to” or whatever makes that focus invalid… then by all means do something else because it literally can’t be focused where it was.
I saw no such argument. (Where?)
I read the “it’s complicated” from @AmberV as saying its too complicated to fix the removal of focus (i.e. to retain focus) in the identified cases because of potential side effects. I could have misunderstood.
AmberV said there is a “huge ticket” about it.
Meaning: the intention to fix it is there.
(At least that’s my understanding. – I might be wrong…)
(Probably “huge” as in : “There is a lot of ground to cover”. – More than in : “Oh God! Oh God! Oh God! (panic faces) Gotta fix that thing right now!!”)
Meanwhile… : using automations such as provided by AutoHotKey, I am pretty confident there is a way to design a script (a couple, actually – one per case) that would handle that.
It would do the navigation, then restore the focus to where you want it.
(I don’t know AHK enough to program such a script myself, but I totally see it as doable.)
My cynical s/w & IT background shows through: “huge ticket” = big, complex, too many Agile points to do in one sprint… it’s an Epic… and we can do so many nice little things instead… maybe some other time.
If it were easy, it wouldn’t be a “huge ticket” and would probably have been done.
I have no complaints; I am deeply impressed by what they have delivered, sometimes confused about some of approaches to edge cases, but hugely supportive 
But a user can dream, can’t he? 
I am not the one who’s gonna either blame or try to stop you.
And you made your point. You are probably right.
Workaround time.
To reiterate, there is a huge ticket on it. There is no reason to speculate on why anything works the way it does currently. Most of it is not correct.
I think you are being a little too defensive. I was agreeing with you, and probably on more points than you realise given the limited scope of your request.
…To say that I almost rather replied “we should just wait and see if AmberV will clarify the question”…
I should’ve known better.
My IT knowledge/experience, in short, is that it’s a clown living in the sewers…
Ah. My spectral shortcomings show through: I didn’t understand agreement. Sorry about that.