Month-range picker · round 4 — the whole popover

1 · Draft-only. Nothing commits or closes on a pick; Apply is the sole commit path (you, 2026-07-15: “as soon as they choose, it closes. I don’t like that”).
2 · Quick ranges stay primary, specific months stay a disclosure (you, round 2: “people aren’t gonna click months — focus on the quick options, and if they want specific they can click specific”). Two always-open From/To fields promoted to the top level reverses this — disqualified.
3 · An old year must not cost a click per year. The year column exists because a chevron stepper put 2000 twenty-six clicks away.
4 · Which endpoint the next click sets must be visible at all times. Pre-C3 was implicit (first click starts, second ends) and that was the defect.
5 · Future months unselectable. 6 · ~300px anchored popover; it may open upward. 7 · The year column is ONE tab stop, not 27.

Takes “if it could expand” literally. The popover has two pages, not one page with a fold — page 2 is the picker occupying the whole popover. The disclosure’s caret becomes a right chevron (navigates, not unfolds). From/To become two ordinary menu rows in the same idiom as the quick ranges above, so nothing on screen is card-edge chrome and nothing is enclosed in anything. The grid gets the popover’s full width.

The cost: it removes the primary control from view to show the secondary one. Your own stated priority is that quick ranges are what people use — A is the only viable direction where a user inside the picker can no longer see them, so a mis-entry costs a Back. It also gives a stateless surface navigation state (focus on entry/exit, Escape per page, bottom-anchored height when flipped) — small-bug surface that B simply does not have.

Takes you at your word — “if it wasn’t in a card it would be okay” — and just deletes the card. Same fold, same mechanics as today; the folder tabs and the panel they fused into are gone. From/To become a full-width segmented control, the same idiom the granularity control already uses, so the popover has one way of saying “pick one of N inline”. The picker sits bare on the popover surface: no border, no fill, no radius. What is left is menu-with-separators grammar, which nobody reads as nested.

The cost: the least ambitious, and the most exposed to you having meant something structural. A segmented control holding two values above a grid is the tabs’ information architecture without the tabs’ costume — if you look at it and still say “nested thing”, we’ve spent a round. It is also the tallest expanded (~580px), which is what has always made the open-upward case awkward.

Solves the nesting by never showing two states at once. One grid, one caption naming the endpoint in words — “Start month · 1 of 2”, then “End month · 2 of 2”. There is no chooser above the grid to read as chrome, so this is the only direction where nothing structurally resembles a tab. In step 2 every cell before the start is disabled alongside the future ones, and the span tints as you hover. Reopening an existing range lands on step 2, where both endpoints are visible and either is one click away.

The cost: linearity. Changing just the end is fine; changing just the start is header-link → pick → Next → Apply — one step more than A or B. Anyone who thinks of a range as two independent handles will find it slower.

Quick ranges stay on the left, the picker opens as a sibling pane on the right, divided by one vertical hairline — the column-browser pattern, and a sibling is the opposite of a nested child. Genuinely good, and it has a bonus: with the presets still visible, clicking “Trailing 6 months” could paint the grid to show what it means.

Why it is not on the table as drawn: a 600px popover is not a 300px popover. It needs horizontal flip logic and a degraded layout for viewports it cannot fit, so you build two. And the bonus is a trap — quick ranges commit today, but inside a pane with an Apply button they would have to become drafts, so the same row would mean two different things depending on state. Say the word if you want the width assumption reopened and this becomes buildable.

The obvious suggestion, and it fails on your own complaint: it re-creates the nesting four times over — each select is a popover opening inside the popover, and a 27-row year list overflows the panel, badly in the open-upward case. You also lose the range as a shape: no painted span, no sense of “5 months”, no glance-check that Aug is after Apr. And “future months unselectable” stops being free and becomes a cross-field rule — December disabled in 2026, enabled in 2025, the year select reacting to the month. Every constraint it meets, it meets worse than A, B or D.