There should be a place (places due to RC vs. watchlist issue) on the backend where you can configure:

• Groups
  • Mark groups that are full coverage (if you check everything, all entries are included). As opposed to things like 'Content type'.
  • Group explanation (what's this from T159186: Implement 'What's This' Links on the dropdown filter panel)
    • Header i18n
    • Body i18n
    • Link text i18n
    • URL
  • The prioritization (where it appears in the group list)
• If no filters are usable in the group, the group is not emitted to the front-end.

• What filters there are
• Whether they are available on new RC page, or both old and new.
• The default value (may be based on a preference, can vary by watchlist vs. RC, e.g. 'hideminor' vs. 'watchlisthideminor' preferences) (the default can vary for non-preference cases too)
• The actual modification this makes to the DB query
• Prioritization (where it appears in the filter list)
• Pass in callbacks to a registration method, and disable if there are any required ones missing:
  • T152797: Attribute RC lines to their sources
  • isAllowedCallable - Check dynamically whether the filter is allowed; currently, this is only available on filters, not groups, since otherwise you might accidentally disable extension-defined filters that don't need to be disabled.
• Filters that imply/control other filters (e.g. if you select "Likely have problems", it should also find edits that are "Very likely have problems"). More information is at T149452: Build user interface for the Dropdown Filter Panel. This includes (all separate cases even if the rendering happens to be the same):
  • Auto-drop URL conflicts like T151873: Redirect when a URL cannot be adapted to the new filter system for Recent Changes
  • Cases where selecting one affects the other, and the UI could indicate that:
    • One filter implies another, so selecting the other would have no effect (e.g. likely damaging is a super set of very likely damaging).
    • Conflict: Only good-faith edits, log entries are grayed out. This should support conflicting with an individual filter, or a whole group. Two sets of custom i18n entries:
      • See T156427 for near Results Area message e.g. "The "New user" filter includes only registered users conflicting with the "Unregistered" filter."
      • Conflict tooltips
      • Initial conflicts:
        • ORES vs. Wikidata
        • ORES vs. Logged actions
        • User experience level vs. Unregistered
• Anything can register these no effect/conflict, not just when first defined (to support extensions).
• exclusion: 'default' does not exist.
• isReplacedInStructuredUi => true (URL always works, always shows in old UI (since JS might be off), removed by JS using CSS class)

This needs to extensible by extensions (we already have a need for this, e.g. ORES, Wikidata, Translate).

I suggest hooks would be a good option for extensibility, but @Mooeypoo points out having extensions modify a wg could work.

In output for new rcfilters UI:

• If possible, backend converts 'all' to actual default values (e.g. comma-sep).
• Doesn't need to redirect 'all' URL, but would be nice if it's all *and* other stuff.
• Don't need to omit default: false.
  • For send_unselected type, default: false means that this parameter is not active (e.g. for 'hideanons', default: false means anons are not hidden by default).
• Numeric values (e.g. rcdays) to be solved later.

In output for old rcfilters UI, same except:

• Data attribute of filter name to hide/show link.
• Tag filter links with class for whether they exist in the new implementation (data-also-structured-ui) (this needs to take account isReplacedInStructuredUi)