The existing filters can be used to accomplish this.

Registered: hideanons=1
Unregistered: hideliu=1

It is possible to use both of those filters together, in which case it does something unexpected[1], but using them carefully works. Do we want to use them or add a new-style filter (userRegistration=registered|unregistered|all)?

[1]

if ( $opts['hideanons'] && $opts['hideliu'] ) {
	if ( $opts['hidebots'] ) {
		$hideanons = false;
	} else {
		$botsonly = true;
	}
}

If I read that code correctly, it's saying the system will always show something, even if the user says not to? Pinging @Pginer-WMF, but I'm pretty sure he'll agree that the new implementation has no room for such hidden functionality. (And no need, since our system would not allow the user to hide both registered and unregistered in any case.)

I.e., stick to the spec above: if neither is checked, then it's the same as if both are checked -- the function returns registered and unregistered.

Some of the complexities of the existing model seem to come by the diversity of actions ("hide x" vs "show only y"). Our proposed approach is based on describing a list of properties you want to see in the results (and considering that mentioning nothing means not adding any restriction).

I don't have a preference on how to better express filters on the API as long they support the intended user behaviour at the UI level.
For a filter such as "newcomer + experienced + good-faith", I can imagine multiple representations ("filters: newcomer, experienced, good-faith", "(newcomer OR experienced) AND good-faith", "showNewcomer=1, showExperienced=1, showGoodFaith=1") but the concept of "hide" does not seem very intuitive here.

Another relevant question is what do we want to do in terms of backward compatibility. If we change the way filters are expressed, do we want people with old bookmarks to be redirected to the new naming system to avoid breaking their workflows? (I think it would be desirable but I'm not sure how complex it would be or how many people reach the page base on external links/bookmarks).

Related to this, I created a ticket about communicating contradicting filtering parameters that cannot be represented in the current model: T151873: Redirect when a URL cannot be adapted to the new filter system for Recent Changes