Here's the idea:
What if we allowed for parent selection rules to be added to a per-remap basis? I can imagine several ways to configure this (so don't pick the example apart), but e.g.
These per-remap parent config rules would no longer require a selector such as dest_domain or dest_host. A configuration file could (and probably will) be shared across many remap rules, so some sort of control on ownership and reloading of that is necessary (hence TS-4642).
Not only would this be nicer to manage and configure, it'd also be a lot more efficient (since we avoid the additional selection of parents after remap). This is similar to the "Lua scriptlet" ideas, except we'd basically just incorporate existing configuration management and selection into remap.config.
In addition, there are several other similar configuration files that could benefit from this overall idea. Like, cache.config could then be used as a @cache=example_cache.config, avoiding potentially expensive selectors.
John Rushford What are your thoughts on this idea? Is it worth pursuing? I haven't looked at the code, but it'd require us to be able to attach a parent.config parsed object to each remap rule, and manage the creation / deletion of those as remap.config is reloaded.