So, we accidentally ran an experiment with having no drag zone in maximized windows in M68 stable -- I broke it.  The outcry was immediate, and we merged a change back to fix it.  Turns out a lot of people with multiple monitors drag maximized windows.

The drag width right now is 50 DIP, which is close to the 45 DIP of the Win 10 caption buttons.  I'm not opposed to changing the 50 to 45 to coincidentally match, but note that the drag width is a cross-platform constant and the caption button width is Win 10-specific.  We shouldn't assume that the width is "matching" or that that should be a goal, unless there were a width that would match across all platforms.

Regarding the smallest visible tab, we intend to change that with tab overflow, so keeping the two locked in sync doesn't make much sense to me.  And the tabs have a pretty different interaction model -- their purpose is primarily to display information, secondarily for targeting, and there are alternate keyboard-driven ways of targeting.  Whereas the drag region is solely for interaction and always mouse-driven.

We can't really go narrower than 45 DIP lest we run afoul of WCAG.  So if we're trying to eke a few more px of tab space, I'd say drop from 50 to 45 and be done.

 Issue 881831  has been merged into this issue.

You say the 50 DIP are cross-platform -- does that include the room for the window close buttons on windows?

No, 50 DIP of drag handle, plus caption buttons.

Pre-refresh we let the right edge of the NTB run up to very near the caption buttons, especially in restored mode; but in Refresh the window is less draggable from the top and the drag handle width is intended to be the primary way people drag.

Feel free to reassign as necessary.

If you're assigning to me to make a call, my call is to do nothing.