I updated the demo — P4786 — and wasn't able to reproduce the problem there:

@Volker_E, from MediaWiki-extensions-ApiSandbox (not an extension anymore, I guess) perspective this might not be Lowest priority.

@Prtksxna I've changed to lowest while we're waiting to hear back from @Schnark after you've tried to ans couldn't reproduce it

Well, all I can say that the issue does show reproducibly on Special:APISandbox, in any wiki (so it can't be some local CSS causing this), and any browser.

It's because of the position:relative; of .oo-ui-dropdownWidget. Not sure exactly how that influences stacking order (stacking order is not something I've had to deal with much).

This only happens when the PopupButtonWidget is inside a ButtonGroupWidget. ButtonGroupWidget creates a new stacking context (with z-index: 0), so that we can change z-index of buttons inside (to cancel out the duplicate borders between items in a fancy way) – but this also causes PopupButtonWidget's popup (which has z-index: 1, and which would normally appear on top) not to be able to escape this stacking context and display below subsequent positioned elements (like DropdownInputWidget's handle).

Change 341049 had a related patch set uploaded (by matmarex):
[mediawiki/core] mw.special.apisandbox: Pass $overlay to PopupButtonWidgets to fix overlaps

https://gerrit.wikimedia.org/r/341049

Hmm, apparently this only happens with Vector. Monobook is fine.

Yeah, only the MediaWiki theme of OOjs UI. We don't have the fancy duplicate-button-border-cancelling in the Apex theme.

@matmarex Clarifying question, what do you mean by “fancy duplicate-button-border-cancelling”?

Change 341049 merged by jenkins-bot:
[mediawiki/core] mw.special.apisandbox: Pass $overlay to PopupButtonWidgets to fix overlaps

https://gerrit.wikimedia.org/r/341049

In T155992#3072133, @Volker_E wrote:

@matmarex Clarifying question, what do you mean by “fancy duplicate-button-border-cancelling”?

Buttons in ButtonGroupWidget share the inner borders. The border between two buttons actually belongs to the second button (the right one, in LTR).

The fancy part is: because the border colors differ in MediaWiki theme, and because some are more important than others, we sometimes want some buttons to take over both sides of the border.

Consider this example (you can copy-paste into browser console on the demo page):

var group = new OO.ui.ButtonGroupWidget( {
	items: [
		new OO.ui.ButtonWidget( {
			label: 'One'
		} ),
		new OO.ui.ToggleButtonWidget( {
			value: true,
			label: 'Two'
		} ),
		new OO.ui.ButtonWidget( {
			label: 'Three'
		} ),
		new OO.ui.ButtonWidget( {
			disabled: true,
			label: 'Four'
		} ),
		new OO.ui.ButtonWidget( {
			label: 'Five'
		} ),
		new OO.ui.ButtonWidget( {
			// Click this button to focus it
			label: 'Six'
		} ),
		new OO.ui.ButtonWidget( {
			label: 'Seven'
		} )
	]
} );
$( 'body' ).empty().append( group.$element );

At 3x zoom:

Note how the toggled button ("Two") and the focussed button ("Six") take over the border on both sides to set their color. Note how the disabled button ("Four") does not take over the border on either side, allowing other buttons to set its color. This is done with z-indices:

.theme-oo-ui-buttonGroupWidget () {
...
	// Create a stacking context, so that we can use `z-index` below without leaking out
	z-index: 0;
	position: relative;
...
	// Give hovered/focussed/active buttons higher `z-index`, so that borders display right.
	// Identical to .theme-oo-ui-buttonSelectWidget, except for the `:focus` selector.
	&.oo-ui-widget-enabled {
		.oo-ui-buttonElement {
			&.oo-ui-widget-enabled > .oo-ui-buttonElement-button:hover,
			&.oo-ui-widget-enabled > .oo-ui-buttonElement-button:active {
				z-index: 1;
			}

			&.oo-ui-widget-enabled > .oo-ui-buttonElement-button:focus {
				z-index: 2;
			}

			&.oo-ui-buttonElement-active > .oo-ui-buttonElement-button {
				z-index: 3;
			}

			&.oo-ui-widget-disabled > .oo-ui-buttonElement-button {
				z-index: -1;
			}
		}
	}
...
}