Tests in CI are running on Chrome Headless which has a different user agent, making this.safari === true. This is what caused the original test failures; it was just a test issue.

This was just WebStorm complaining that the escape was not necessary.

I wonder if this a step too far... would it be worthwhile to preserve that jQuery behavior by filtering querySelectorAll results like e.g. elem => jQuery.find.matchesSelector( elem, "#" + ephemeralId + " *" ) or elem => jQuery.contains( context, elem )?

There's also a larger but more performant version of the former using rudimentary selector transformation, e.g.

// Prefix each item in the `selector` list with a scope prefix.
var match,
	extracts = [],
	// Helper here for clarity, inlining at its two call sites probably compresses better.
	restore = s => s.replace( /'(\d+)'/g, (_, i) => extracts[ i - 1 ] );

// Temporarily replace backslash escapes and strings,
// which could otherwise disrupt identification of the list's constituent selectors
// (e.g., `a\\,[attr*='foo,bar']`)
selector = selector.replace(
	/\\[^]|(['"])(?:\\[^]|(?!\1)[^\\])*\1/g,
	s => "'" + extracts.push( s ) + "'"
);

// Likewise for functional pseudo-classes, but recursively
// (e.g., `:not(:is(h1,h2), article header)`).
while ( (match = /([^]*?)(\([^()]*,[^()]*\))([^]*)/.exec(selector)) ) {
	selector = match[ 1 ] +
		"'" + extracts.push( restore( match[ 2 ] ) ) + "'" +
		match[ 3 ];
}

// Prefix and restore replacements in each selector of the list.
selector = selector.replace(
	/[^,]+/g,
	// ...but don't prefix selectors that already start with a :scope pseudo.
	sel => restore( sel )
		.replace( /^(?![ \t\r\n\f]*:scope(?![\\\w-]|[^\0-\x7f]))/, scopePrefix )
);

(where scopePrefix is either ":scope " or "#" + ephemeralId + " ")

@gibson042 The issue is not that the results are not children of the context but that not the whole selector matches the contents part. It seems to me that just checking elem => jQuery.find.matchesSelector( elem, "#" + ephemeralId + " *" ) or elem => jQuery.contains( context, elem ) doesn't find those issues?

To make sure the whole selector matches within the context, we'd need to first split the selector list into individual selectors which requires some parsing; that would make selector-native much larger. Am I missing anything?

No, that's right. It would not be covered by the simple filters, but would be covered by the rewriting.

OK, would you like any further changes to this module for 4.0.0 then?

That behavioral seems really severe to me, but if consumers tolerate it then I guess it's fine.

@gibson042 I'm checking this right now but would you mind merging this PR as-is and exploring such an extension in a separate one? This PR largely restores the current 3.x version of selector-native so I feel it'd be beneficial to separate extending it.

My preliminary checks seem to indicate resolving this issue would cost about 1000 bytes minified gzipped; it'd still be 3300 bytes minified gzipped smaller than the full build compared to 4300 bytes minified gzipped without this change.

@timmywil @gibson042 what do you think? Is it a good idea? I can prepare a POC PR. I'd still like to keep it separate from this one, though.

I agree with separating it, since selector-native has always had such a limitation.

I created #5185 to track this issue.

...and a PR to review: #5186.