Steps to Reproduce:

1. Go to Special:Log on a wiki
2. Notice the "User creation log" filter is checked by default
3. Uncheck the filter and click "Show"

Actual Results:

• The filter is checked again and user creations are possibly shown in the results.

Expected Results:

• The filter is unchecked and user creations are never shown in the results.

Now try the same but also check some unchecked auxiliary filter (e.g. "Patrol log").
After submission, "User creation log" is now unchecked (and the other filter is checked as expected).

Investigation:

The filter was introduced with this change which was first uploaded by @Bawolff in 2017 and approved in 2020.
(@Raymond reported this problem at the patch in Gerrit shortly after it was merged.)
In 2018, Special:Log was refactored by @Prtksxna (T117737) and I did some code cleanup in 2019:

public function getFilterParams() {
	$filters = [];
	if ( count( $this->types ) ) {
		return $filters;
	}
	$wpfilters = $this->getRequest()->getArray( "wpfilters" );
	$filterLogTypes = $this->getConfig()->get( 'FilterLogTypes' );
	foreach ( $filterLogTypes as $type => $default ) {
		// Back-compat: Check old URL params if the new param wasn't passed
		if ( $wpfilters === null ) {
			$hide = $this->getRequest()->getBool( "hide_{$type}_log", $default );
		} else {
			$hide = !in_array( $type, $wpfilters );
		}
		$filters[$type] = $hide;
	}
	return $filters;
}

$wgFilterLogTypes = [
	'patrol' => true,
	'tag' => true,
	'newusers' => false,
];

The "back-compat" is for pre-2018 URLs which used ?hide_(type)_log=1 (this was in place when the 2017 change was first uploaded).
If you try https://en.wikipedia.org/wiki/Special:Log?hide_newusers_log=1, it works as you would expect and unchecks and hides "User creation log".
However, the 2018 form creates URLs with ?wpfilters[]=(type). If a log type is specified this way, it will be shown in the results. But when no filter is checked, this URL param is not appended to the URL and then ($wpfilters === null) either the legacy param (which is never generated by the form) or the default value (from $wgFilterLogTypes) is used.

Possible solutions:

1. Fix the form to correctly treat false values in $wgFilterLogTypes
2. Add some hack (URL param) which would change the behavior when no wpfilters[]= was specified.
   • Instead of "fall back to default", it would just "hide all".
3. Return to hide_(type)_log= params and forget about wpfilters[]=.