I think putting the multiple document close icons in a submenu would be good UI design, so people don't accidentally click them. They should be harder to use.
I think the opposite, when possible/not too big, IMO it's better to keep a flat menu structure so it's easier to use and requires less clicks (and less mnemonics if you use accelerators). It's not like closing documents is dangerous and presumably it's rare even with a lousy trackpad or muscle control.
A nice thing about #2348 is that it alleviates my main concern that the menu was too crowded and allows stuff like this PR to get rid of the submenu and also adding items like "close to the left" or "open in split window" or whatever stuff we want.
I was pointing out the close order difference of this pull vs the sidebar documents close folder. Perhaps the latter should close in tab order too rather than alphabetic order?
IMO, the reasoning in #2347 is sound and should apply to any operation on multiple tabs (closing, searching, etc.) no matter which feature triggers the action.
Maybe you keep all files in a project open always.
My usual workflow is to keep maybe 1-15 tabs open, and close them when I don't need them for the time being (often using one of the multi-close menu items in the tab menu). I usually open documents using the ProjectOrganizer treeview, with one or two folders expanded, so there's no reason for me to keep loads of files open, every file in the project is a double-click away. It helps that I have a 4k monitor without scaling, so I can see lots of files at a glance in the sidebar.
It only adds one menu item, (and the multiple document close items should be put in a submenu as I mentioned).
If #2348 gets merged, I have no objections to this PR whatsoever, and even without, I don't feel strongly against this PR, I just most likely won't use it.