>> Agreed.  Although currently I have no idea how to do this without adding
>> direct calls of tab-bar.el functions in desktop.el.
>
> It isn't a crime.  It is also not a catastrophe to have in desktop.el
> code that knows something about tab-bar.el's code.  We already have
> such code in desktop.el that knows something about some minor modes.

So now this is implemented in the attached patch.  The call to
tab-bar-mode takes care about recalculating the correct values
of the tab-bar-line frame parameter.

>> Such a solution is also needed for GUI frames as well, because
>> when tab-bar-mode is not enabled explicitly, then after restoring
>> the desktop with tab-bar-line frame parameters, tab buttons are too ugly.
>> The graphical versions of these buttons are created only when
>> tab-bar-mode is enabled on a GUI frame.  So desktop.el should
>> enable tab-bar-mode somehow.
>
> Yes, what I proposed will work for any kind of frame, because
> tab-bar-mode calculates the metrics of the tab bar, so doesn't need it
> to be already calculated in advance.

The same call to tab-bar-mode also takes care about creating the buttons.

>> tab-bar-lines are updated according to the value of tab-bar-show
>> in tab-bar--update-tab-bar-lines (called from tab-bar-mode).
>
> Yes, but what about future frames?  The use case is: the user restores
> a session from desktop file, then proceeds creating new frames with
> tab bars of different numbers of tabs.  We'd want tab-bar-show to be
> restored from the desktop as well, so that the tab bars on the new
> frames behave the same as the user defined in the session that was
> restored, no?

tab-bar-mode takes care about future frames by adjusting default-frame-alist.

>> But this raises another question: when the user changes the value
>> of tab-bar-show, should desktop.el show the tab bar exactly as saved,
>> or should it update the tab bar according to the new value of tab-bar-show
>> immediately after restoring the desktop?
>
> I think the idea always was that restoring desktop overrides any local
> changes of the saved variables.  Users that want it the other way
> around should edit their init files to move the desktop restoration
> code before the code which modifies the variables which could be
> restored.  I think.

Right, the users can change the order in their init files
to customize this behavior.