Change:
When a quickpick has more items than can fit into the initial list, it's not obvious there are hidden items that need to be scrolled into view. The current visual treatment is a very subtle scrollbar flash when the quickpick is first opened, but thereafter there is no visual indication that there are more items. The current behavior presents issues for the remote indicator menu, which displays actions from all installed remote extensions (connect to host, create new codespace) etc. The remote indicator menu is meant to improve discoverability and ease of access to remote actions, and the current truncation inhibits discoverability of those remote actions. Proposals: a arrow button at the bottom of the quickpick when there are items offscreen which will scroll down to the next 'page' of items when clicked render the scrollbar
Looking at prior art here: Slack ! Spotlight ! GitHub ! Teams ! Alfred ! Docker ! One thing I'm noticing is that some render the height as the middle of an item... which is an indication that there is scroll. Not sure if that is intentional or not, but it would be something that we have control of. While the is a neat idea, I fear that it will be in the way while reading the item it is on top of... My preference is either render the scroll bar... or maybe do nothing since the "command palette" experience can be seen across many products and most if not all allow scrolling.
Oh, I wanted to point out that the scroll bar does flash today: ! and if your mouse is hovering over the list, the scrollbar sticks around. This feels like enough of an indication that there's scroll.
Instead of rendering it atop an item, what if we rendered it below all the items in the quickpick?
Do you not think the flashing scroll bar is enough? The Explorer does this too.
I don't think it's enough, particularly for the remote indicator scenario where you're triggering it by clicking the status bar--there will be a brief flash when it's first opened, and if you then use up/down arrows to navigate through the list, you don't see the scrollbar.
Is this a hunch or based on user feedback? I talked to a bit about how the fading went when we rolled it out everywhere and there were some issues opened: not scoped to quickpick but rather holistically. We have settings to control the behavior but only in the editor I guess: ! in terms of proposal 1 for scrollbar visibility, I feel like the issues I linked are a better holistic way forward. As for the ... I'm not sold. Either it makes the quick pick taller (just for a little arrow) or it covers up content.... plus I couldn't find a single quick pick example in the wild that takes this approach.
I think it's fair to consider a global treatment for scrollable content as you say, the linked proposals look promising.
Proposed solution: increase the by a little bit so it renders like: !
steps to verify: open the command palette it should render in the middle of the item (like my last screenshot) to indicate that it does scroll

Discussion:
} layout(maxHeight?: number): void { <del> this.list.getHTMLElement().style.maxHeight = maxHeight ? `calc(${Math.floor(maxHeight / 44) * 44}px)` : ''; </del> <ins> this.list.getHTMLElement().style.maxHeight = maxHeight ? `${ // Make sure height aligns with list item heights Math.floor(maxHeight / 44) * 44 // Add some extra height so that it's clear there's more to scroll + 6 }px` : ''; </ins> this.list.layout(); }