I think the answer for "A" and "B" is almost certainly that both packages still own the file, and the more specific claim made by "B" does not invalidate the claim made by "A". In particular, "A" can add paths in "B" with 'exclude' rules if the intent is truly for "B" to exclusively own the files.

Permissions are a little flimsy right now, but this approach also simplifies this situation in the future:

• An attacker wants to modify /x/secret.c without being detected, but /x/ is owned and has audit rules.

The attacker should not be able to weaken audit rules by creating a new package which owns just /x/secret.c. This is much easier to accomplish if the other package's claim just gets to stand. If /x/secret.c is some codegen thing that no one cares about, it can be excluded.

Ordering packages by specificity still seems useful, it just shouldn't invalidate claims made by more general packages.

Given that, the "C" and "D" use case is probably also fine. @nickz has an example like this:

• Package C owns /ios/ and /shared/config.xml
• Package D owns /android/ and /shared/config.xml

This is a little odd, but seems basically reasonable, and generally increases the power of packages.

The consequence of embracing these rules is that the table of contents needs to list all the packages a file belongs to, which starts getting messy, but this is mostly voluntary complexity. Now that the TOC is unified we're in a more reasonable position to tackle general UI improvements or view options, anyway.

For binding builds to packages to work I think they need to overlap. For example: Run the 'Super Sweet Selinium Spaces Tests' if src/applications/spaces OR src/infrastructure changes, but src/infrastructure is also a trigger for other packages.

Ah, thanks! That use case makes sense to me too.

Owners is mostly just super old and was largely defined by implicit behaviors, some of which were really bugs. Getting a handle on some of these use cases helps me figure out what's a bug or accident vs what's actually desirable behavior that we want to build or retain.