Draft. I am not sure I am fully understanding it, so I am sharing it here to gather feedback before posting it.
Yay! Let’s try to make this fork short-lived!
Yes! 
Note that Tails’ version has changed quite a lot since you forked – please try to keep your fork delta minimal (i.e. only do what must be done)!
Our diff of the filter is quite mergable, I guess. In summary:
- filters = yaml.safe_load(fh.read())
- #!/usr/bin/python3 -u so python exceptions end up in journal
- config parser
- –listen-interface (which you already said you want to add)
(And the packaging stuff is not all that difficult?)
We have a ticket for merging Tails’ version into Whonix’s version so we get your enhancement and so the diff looks simpler. [1]
So, since all your filters match everything, you could actually merge all the filters yourself into a single filter rule file, right? In fact, the only non-sytlistic reason you want merging of multiple matched rules is to allow Whonix users to add their own filters without overwriting yours (which causes issues during Whonix upgrades), correct?
If so, I think I have a simpler solution: we introduce a new top-level key called override which takes a list of strings. If such a filter is matched together with a filter whose name is listed in override, then the override-filter is merged into the other one, and has priority whenever there’s any ambiguity. So with this, Whonix would ship a single, nicely commented filter called ‘whonix’, and users that need to modify it simply creates a filter with override: ['whonix'].
The only drawback I can see is that Whonix cannot organize the filters in separate files this way, but I think that is a small prize to pay for such a simple solution to this problem (which I fear otherwise can make it really hard to reason about filters when they grow in number). I actually think Whonix having a single file is slightly advantageous since you use the same match rules in every filter.
Would this work for you?
No. (However, I am not sure I fully understood your proposal. Technically at the moment all config file snippets are merged into the same merged filter rule.)
Having the filters split in multiple files is very much desirable. We want to ship a maximally restrictive config by default. And then allow users to make it more permissive as required depending on their use case.
Just two different configs, one for maximum restrictive vs one for custom maximum permissive is probably not right balance here.
(We match everything because of necessity - to keep the code complexity manageable. Matching by IP would be a nice feature, so would be a profile on the gateway that only matches arm.)
For example, adding onionshare is one of the safer applications one can whitelist due to the limited range of listening ports it opens. ricochet is more crazy, since all ports need to be allowed. (Something being discussed with upstream so this may change for Debian buster.) Some applications want to see the onion’s private key [ricochet, so it can restore it later], for others we can inject DiscardPK and redact it. I think other applications will require access to further Tor internal states. Ricochet uses STATUS_CLIENT, but fortunately also does not break without it yet.
Having to use something like “override: [‘whonix’]” and somehow have a hierarchy of files named that way, if they are splittable/stackable, would of course not be an issue.
Beyond that, I’ll add your --listen-interface option, and I’ll add a --filters-dir option that can be used to override the default filters dir, and that can be passed multiple times (so you’ll pass --filters-dir /etc/tor-controlport-filter.d --filters-dir /usr/local/etc/tor-controlport-filter.d/).
That’s great! (Please don’t fail if the folder does not exist - logging that only would be a lot better.)
[1] ⚓ T612 merge tor-control-port-filter changes by Tails into Whonix's tor-control-port-filter fork