>         >         > WIP patch attached with a test and some few refinements
>         we've
>         >         talked about
>         >         > in this dialog.  I didn't alter tab-bar-mode to
>         tab-bar-lines as
>         >         Martin
>         >         > suggested.  You're the expert.
>         >
>         >         We don't need a new unusable option, so please remove it
>         and submit
>         >         a new patch.
>         >         Also please replace tab-bar-mode with tab-bar-lines like
>         Martin
>         >         suggested.
>         >         Then everything should be good.  Also it seems you forgot
>         to remove
>         >         window-dedicated-p in your previous patch.
>         >
>         >     I'll work on that now.  I'll remove
>         >     'window-delete-active-tabs-inhibit-delete-frame'.
>         'window-dedicated-p'
>         >     condition now gone.
>         >
>         >     Are you sure you don't want this to support the case where
>         tab-bar-mode
>         >     is active and tabs merely aren't visible?
>         >
>         > There's also 'tab-bar--tab-bar-lines-for-frame' if you think
>         that's more
>         > appropriate.
>
>         'tab-bar--tab-bar-lines-for-frame' is used to set tab-bar-lines,
>         but you need only to get it.
>
>         > All tests pass unless I set tab-bar-show nil, and I still think
>         this patch
>         > should work even if the tab-bar is hidden, but tab-bar-mode is
>         enabled.
>
>         It's a different situation when you see tabs like in a web browser.
>         They have even an option "Ask before closing multiple tabs".
>         We could add a similar option instead of the above one,
>         with 3 possible values like
>
>         1. nil - don't ask and close all tabs
>         2. t - close only the current tab
>         3. 'ask - ask a confirmation
>
>     Hmm.  Well Emacs isn't a web browser, but I hear you.  I'll try out an
>     option like that and see how it feels.  I haven't looked deeply, but if
>     we prompt inside window functions and there are state changes along the
>     code path before the prompt that we can't undo if the user quits while
>     prompted, I don't think we need that level of complexity.  Maybe we can
>     prompt before state changes using window-deletable-p output as an
>     indication.  Again, not looked that deeply yet.
>
> As I guessed, it's not easy to find the right place(s) to put a prompt
> before state changed or undoing state is easy.  May I suggest that we move
> ahead with the patch I've attached and consider enhancements that may
> include a prompt at a later time?  We can also see how people get on with
> the tab-bar-lines condition vs. just tab-bar-mode (which I still prefer)?

Sorry, this was fixed yesterday following Martin's request in bug#59862.
I've cc-ed you a mail about this, but maybe you missed it?
Could you please update your patch from current master?