Oops, I only replied to Eli. I'll send my explanation, and new patch. 

> When the variable tab-bar-new-tab-choice is set to t, the intended
> behavior is to create a new tab with a single window, and that single
> window displaying the current buffer of the currently selected window,
> and the new window should have a fresh set of window parameters.

> Typically, this is done by first calling delete-other-windows, so the
> currently selected window is the only window. The call to
> delete-other-windows also ignores window-parameters, so even windows
> that have the no-delete-other-windows parameter still get deleted. Then,
> the current window is split, to create a fresh new window with fresh
> window parameters, and then delete-window is called to delete the
> currently selected window.

> This strategy doesn't work when the current window is a side-window,
> because delete-other-windows has a check which says that a side-window
> cannot be the only window in a frame. So, to work around this, we just
> remove the window-side parameter beforehand, so the above strategy still
> works.

> Another way we could do this was to get the current-buffer, then delete
> all side-windows. After deleting all side-windows, we know the current
> selected window is NOT a side-window, and then we can call
> delete-other-windows, split-window, and delete-window.

On Mon, Mar 27, 2023, at 12:06 PM, Eli Zaretskii wrote:
>> From: Juri Linkov <juri@linkov.net>
>> Cc: bensonchu457@fastmail.com,  62427@debbugs.gnu.org
>> Date: Mon, 27 Mar 2023 19:39:25 +0300
>> 
>> > Maybe I'll agree, but I still don't understand the problem well
>> > enough.  Would you please explain the original problem that led
>> > tab-bar.el to care about these window parameters?
>> 
>> Sorry, I can't explain.  I just did that Martin said to do
>> in bug#53662.
>
> That's okay, Benson Chu explained it.
>
> Let me think about this.