Considering the following interaction:

HEAD https://my.pod/container/resource
200
Link: </container/resource.acl>; rel="acl"
---
GET https://my.pod/container/resource.acl
404
--- 
HEAD https://my.pod/container
200
Link: </container/.acl>; rel="acl"
---
GET https://my.pod/container/.acl
200
<#some-rule>
    a acl:Authorization;
    acl:agent <https://my.pod/somewebid#me>;
    acl:accessTo <https://my.pod/container/resource>;
    acl:mode
        acl:Read.
...

The ACL document https://my.pod/container/.acl contains a resource-scoped ACL rule #some-rule that applies to /container/resource, while the target resource https://my.pod/container/resource does not have an ACL document attached (i.e. the Link with rel=acl 404s).

Is this something that should be allowed by the spec, or does the absence of an ACL document at the place advertised by the resource via the Link header entails that only acl:default rules will apply to the resource via its parents ?

If acl:accessTo rules are allowed in any ACL document in the hierarchy, one might design a system where only one root ACL document exists, containing acl:accessTo rules for any resource in the hierarchy. Could this be consistent with having acl:Control access to only a subset of resources ?