sorry if it wasn't clear but this report is specifically referring to behavior of the built in editor in the GUI.

tested on Windows 10 with Octave 8.0.91 (hg id: 82128f652585). compared with Linux, Octave 9.0.0 (hg id: cbeeb8b44c28) (don't have stable built right now to compare).

(1) with a docked (default location) editor window, typing edit or edit <function> changes focus to the Editor window. On linux, when a function is already open in the editor, edit <function> still switches focus back to the editor. On windows, focus switches if a new window is opened, but it doesn't switch if the function is already open (or if there are multiple files open in the editor, if it is already "on top").  it would be preferred for consistent focus-grabbing across platforms.

(2) with an undocked/floating editor window:
On linux, if no functions are open and the editor window has been closed. Typing edit brings up a new editor window with an <unnamed> function open, with focus. subsequent calls to edit or edit <function> will bring the window/tab into focus whether it's minimized, hidden behind other windows, etc., as expected. 

On Windows, with no functions open and the editor window closed, typing edit brings up a new editor window with an <unnamed> function open, with focus. Another call to edit will again bring
focus if it creates a new editor tab. But focus will not be given if the function is already open. Also, if the editor is minimized, the window seems to almost never be Restore'd at all.  HOWEVER, cursor focus seems to be given. the command line window cursor stops responding as if you switched focus, and typing will have seemingly no effect until manually restoring the editor window, and seeing all of the characters were being typed there.    I have also seen this occur without being minimized, where the editor window is behind the main octave window. edit <function> is typed, focus is not given, but typing puts text in the editor window. (in (1) above, when docked, I can't make typing focus issue occur)