Implicit assumptions about status codes

I recently spent some time making the Community Solid Server conform to the status codes requirements in https://github.com/solid/specification/issues/14#issuecomment-683480525. Below are some comments mostly meant as feedback on how these are described in the spec.

One first takeaway is that GET/DELETE requests that target a resource C/R that does not exist need to return a 404 if the agent has Read permissions on either C/R or on C/. I get the idea, in the first case you could first GET C/R to see that it does not exist, and in the second case you could GET C/ and look at the containment triples to get this information. But I couldn't find anything in the spec saying this explicitly, and I do think it would have to have that instead of these implicit assumptions. It also makes me wonder about the case of doing a POST on C/ if C/ does not exist. Is that a 404 if you do not have Append permisisons on C/ but you do have Read permissions on its parent container?

Another case that caused some issues is a DELETE targeting C/R. While the operation would be valid and allowed if the agent has Write permissions on both C/ and C/R, it would be forbidden if C/R does not exist instead of returning a 404. From how I understand it, the reasoning is that this would leak information about the containment triples of C/. The only thing I could find in the spec about this is the non-normative Security Considerations section. Specifically in this case I also wonder why this specific exception is made. In case C/R does exist the request would be allowed, but would this also not leak information about the containment triples of C/? Since if this request succeeds we know that resource existed. To exaggerate, why do I not need Read permissions on C/ when trying to read C/R if it does exist, since that also provides us with information about C/. Unless of course I misinterpreted the original reason the DELETE request was forbidden.

Besides those specifics, a general problem that I had is that I wasn't sure if the linked table talked specifically about WAC, or Solid in general (or a mix between both). E.g., the fact that a PUT targeting C/R needs Append permissions on C/ if C/R does not exist is specified in the WAC spec. But I guess that any other authorization scheme that is put on top of a Solid server should follow similar behaviour since such an action will always modify the containment triples of C/. And vice versa, the 404 response in the first example above, is this a WAC specific thing as well or does this follow from implicit assumptions in the Solid core spec, making it authorization scheme independent?