Change:
this.distributeViewSizes(); } <del> return view; </del> <ins> const result = viewItemToRemove.view; viewItemToRemove.dispose(); return result; </ins> } /**

Discussion:
Type: <bBug</bJust like in the demonstration of Release Notes: 1.80.0, create two initial editor groups, manually move the split in order to create a custom layout. Click in the left editor group and choose "Split editor right". The left editor group is further split in the middle, leaving the initial split where it is. Now close the middle (latest) editor split group again. This will [actual] merge the middle and the right editor groups, although it should [expected] merge the middle and the left editor group, since the left editor group was split previously and gave off the space. This disturbs any custom layout immensely. VS Code version: Code 1.80.0 (, 2023-07-04T15:06:02.407Z) OS version: WindowsNT x64 10.0.

Modes: Remote OS version: Linux x64 5.15.0-76-generic <details<summarySystem Info</summary </details<details<summaryExtensions (54)</summaryExtensionVersion ------ Bookmarks13.3.1 vscode-custom-css7.2.1 vsc-material-theme33.8.0 vsc-material-theme-icons2.8.0 vscode-drawio1.6.6 vscode-edge-devtools2.1.2 jupyter-keymap1.1.2 remote-containers0.299.0 remote-ssh0.102.0 remote-wsl0.80.2 remote-explorer0.4.1 remote-server1.2.1 material-icon-theme4.28.0 restore-editors1.0.1 clipboard-history1.0.7 working-sets2.0.0 multi-cursor-case-preserve1.0.5 flip0.0.4 doxdocgen1.4.0 xslt-xpath1.5.13 gitlens2023.7.705 swap0.0.5 autoscrolldown1.2.1 duplicate1.0.2 gitlab-workflow3.68.0 selected-lines-count1.4.0 cmake-language-support-vscode0.0.9 indent-to-bracket1.2.2 vscode-clangd0.1.24 tasknotify0.0.2 git-graph1.30.0 prettify-json0.0.3 vscode-dotnet-runtime1.6.0 isort2023.10.0 python2023.12.0 vscode-pylance2023.7.10 jupyter2023.6.

jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 cpptools1.16.3 cpptools-extension-pack1.3.0 hexeditor1.9.11 clang-tidy0.5.1 jinjahtml0.20.0 vscode-fileutils3.10.2 vscode-deepl1.0.6 code-spell-checker2.20.5 sort-lines1.10.2 vscode-lldb1.9.2 expand-selection-to-scope0.2.0 change-case1.0.0 save-as-root1.6.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Not knowing how editor group splitting is implemented internally, I have some assumptions and could see a preferred solution. I used tuple formatting to visualize the width's of editor groups in order like : when you manually move the splitter you set a width (absolute or relative, possibly) for both affected editor groups, since you don't know which editor group you want to have a certain width (could be both of course): when you further split one of the editor groups, it should again get an automatic width just like the newly created editor group, e.g. if you split the left of the initial two editor groups: when you close any of the two editor groups with auto width, they should merge and leave the third editor group that still has a manually set width intact: or again calculated to Not sure if this is feasible and compatible with the current implementation, though.
two tab groups with custom layout (move the boundary) left group to the right (expected) observe that the left group it split in two, keeping the original boundary in place the new group the right group reclaims the space and not the left as would be expected Expected: manual boundary remains intact left editor is proportionally split in two the manual boundary remains intact the origin group reclaims the space ! left group to the left inconsistently with the previous example, all editor groups resize proportionally the new group the rightmost group reclaims all the space and not the "original left" as would be expected the left group remains resized Expected: manual boundary remains intact left editor is proportionally split in two the manual boundary remains intact the origin group reclaims the space !

This same inconsistent and unexpected behavior can be observed with vertically split editors as well.
We have to deal with this even many times a day and it's very annoying.
Recording to demonstrate that the initial layout cannot be restored when closing the second editor group: ! From the editor grid, we call with the sizing option that we : Moving to the grid boss for consideration
Would this be better?
This looks perfect. It seemed intuitive to me the whole time
Amazing!!! these below are my opinions, not a directive, forgive my crude form 0:05 creating 3 new split editors consecutively should create 3 equal editors <0:12 adjusting boundaries by hand should lock them in place 0:13 closed editor should allow the closest top or left editor to reclaim the empty place 0:16 splitting an editor into two should create two editors in equal size, not adjusting size of adjacent editors IF the boundary was manually adjusted (locked) 0:21 closed editor should allow the closest top or left editor to reclaim the empty place 0:22 splitting an editor into two should create two editors in equal size, not adjusting size of adjacent editors IF the boundary was manually adjusted (locked) 0:25 closed leftmost/topmost editor should allow the closest right/bottom editor to reclaim the empty place 0:29 closed editor should allow the closest top or left editor to reclaim the empty place 0:30 splitting an editor into two should create two editors in equal size, not adjusting size of adjacent editors IF the boundary was manually adjusted (locked) 0:35 the fourth editor adjusting widths of all other editors was a bit unexpected at first, but then I realised that none of the editors had manually adjusted (locked) boundary, so that was fine , however, just as a note, if in this case, some of the boundaries were manually adjusted (locked), only the remaining editors would yield space to the new editor
I thought the implementation was correct, but now that I read this user's description, I notice he's right as well. The problem is that the setting description doesn't reflect the behavior we have implemented in the grid. The setting says: This is actually misaligned with the implementation. A better description would be: Unless you think the implementation should align with the setting description instead, and track user manual changes?
So, what is the ultimate outcome?

1) fixing implementation to match description or 2) keeping current implementation and updating description Although, after reading it for the tenth time and trying to understand the subtleties, I find the two increasingly more similar. IIUC, the only difference is: 1) If there are four editors , with the boundary between 3|4 having been adjusted. A new editor being created in 1 or 2 or 3 would result in - in other words: resizing to equal parts. Basically what this does is split all editors to equal parts until an editor with adjusted boundary is reached. If 1, only this editor would give space to the new editor and split in half. 2) In the same situation as above , a new editor being created in editor 1 would result in only editor 1 being adjusted as it gives half of its space to the New editor resulting in , regardless of any manual adjustments. If at that moment, all editors were equal size and only in this particular condition, it would instead adjust ALL editors to equal parts. Is my understanding correct? In that case I think I would rather prefer option 1) keep current description and adjust implementation.
Just fyi, the fix from Joao is in our insiders builds for people to play with:
Thank you, so it's not my preferred option 1), but I love it anyway. Awesome job guys! This is so much better now.