You can find all issue tickets related to this feature by filtering with the workbench-auxwindow ("auxiliary windows") label in the issue tracker.
I'll try to keep this answer as up to date as I can with those developments.
There's now a "Open Output in New Window" action in the Output Panel's title menu (source), and Notebooks are supported for floating windows (source).
You can now drag editor tabs out of a window to create a new window for them. If you want to disable this, use the workbench.editor.dragToOpenWindow setting.
Commands and keybinding command IDs include:
workbench.action.editor.copyWithSyntaxHighlightingAction)workbench.action.editor.moveEditorToNextWindow)workbench.action.editor.copyGroupToNextWindow)workbench.action.editor.moveGroupToNextWindow)workbench.action.newWindow)Terminals and search results are also supported in floating/auxiliary windows now too.
The right click / context menus of editor tabs now have the entries "Move into New Window" and "Copy into New Window".
The VS Code team is now experimenting with implementation of floating windows in the latest VS Code Insiders (source: 1.83 release notes and 1.84 release notes). Quoting from the 1.83 release notes:
All editors across all windows operate on the same underlying editor models, so that changes made in one window are reflected live in all other windows. You can create any editor layout in the floating windows and open any editor you like, in as many windows as you want.
For our first working version, we envision that the Status bar would also be present in the floating windows so that editor information - such as line numbers and selection ranges - is shown. Stay tuned for more development in the coming months!
Currently, there is a command named View: Move Active Editor into a New Window (Experimental) with ID workbench.action.experimentalMoveEditorIntoNewWindowAction (if you want to bind a keyboard shortcut to it).
As for right now in the stable release of VS Code, the best workaround I see is to use the File: Open Active File in New Window command, which is bound by default to ctrl/cmd+k,o, or to manually open a new window, and drag the editor over there. But those aren't great because the file will be opened standalone, without any of the context of the workspace it was opened from (without workspace settings, extensions enabled for that workspace, workspace tasks, project configuration for that workspace, etc.). If you don't want that problem, then you can open the same workspace in a new window. I guess the downside of that could be that it could potentially use more system resources (Ex. extension host, filesystem watchers to keep the multiple windows with the same workspace in sync, etc.).
I thought I'd take the opportunity to highlight comments from the issue ticket that explain what makes this a hard problem to tackle / hard feature to implement (seriously- this is why I tell people not to make "+1" / "bump" comments. that thread is a swamp and an absolute nightmare to try to read through if you want to actually find the meaningful discussion). According to the maintainers, the challenge mostly comes difficult architecture changes and keeping good performance (source).