While many users have internalized duplicacy’s filtering system and can “speak it” fluently, new users consistency stumble upon rigidity of the filter file semantics; in particular that the inclusion of sub-item would not be parsed unless the parent item tree is also manually included (and the same for exclusions). This is unnatural and redundant, and what is unnatural and redundant is prone to mistakes. This would be recent example.
I see two-stage approach to address this.
Short term, low risk:
Warn the user about rules that are not reachable. This is a common approach in the firewall world (when some of the rules have no effect due to other overriding rules) or in the world of (good) compilers (none of that fortran 77 rubbish) when they detect and warn about “unreachable” code that is usually indication of a mistake. (user wrote it so it was intended to do something -> but it cannot do anything -> something is not right)
It should be feasible to walk though the filter list and brute-force validate each new statement against preceding ones for reachability (by just building virtual filesystem tree and ensuring that each leaf hangs from an explicitly specified branch). This would catch cases such as in the example above. Then abort until the user fixes the inconsistency in the filters. This will catch users attention and would be better than silently ignoring the statement that the user explicitly wrote.
Long term, high risk:
Attempt to auto-correct. There are simple unambiguous cases – if you see
+Library/Mobile Documents/com~apple~CloudDocs/*
just add
+Library/
+Library/Mobile Documents/
in front of it automatically, because this is the only way how that statement would make sense.
There are other complex scenarios that might require care and it might not be worth the effort to build “language analyzer” just for that; the stage-1 solution may suffice.
But whatever is done - the software should not silently ignore user statements: those should either be used or reported as unreachable.