POST not allowed for auxiliary resources

@csarven @michielbdejong @jeff-zucker

When a POST method request with the Slug header targets an auxiliary resource, the server MUST respond with the 403 status code and response body describing the error. [Source]

This is taken from specification.
It does not seem to fit well with : PR #1527

When a DELETE request targets storage’s root container or its associated ACL resource, the server MUST respond with the 405 status code. Server MUST exclude the DELETE method in the HTTP response header Allow in response to safe method requests [RFC7231]. [Source]

Why not use 405 for both and exclude the method from the headers response ? Is there a conflict with http specifications ?

When I look at it from the error code side it seems also easier to understand for Solid users and devs :
This is certainly a simplification.

• 400 do not exist (resource, content-type, ...)
• 401 user has no authorization (not logging ...)
• 403 user is not allowed ( relates to user permission...)
• 405 method is not allowed in this request (DELETE for root, POST for auxiliary resources, ...)
• 409 conflict (cannot delete container with resources, cannot inserts with patch when deletes fails, cannot create a resource with the same name than an existing container, ...)
• 415 exist but unknown (content-type mime-type is unknown, ...)