First: A CalDAV server can contain arbitrary CalDAV collections, not just calendars. E.g. it is not quite uncommon that the server also contains CardDAV collections (aka addressbooks) or even collections used for file storage. You can figure out the type of a WebDAV collection by looking at its {DAV:}resourcetype property. For CalDAV calendars (a collection containing actual iCalendar objects), that will be {urn:ietf:params:xml:ns:caldav}calendar.
/calendars/tasks
tasks, as an example, could mean VTODOs are managed in this calendar
Correct. The collection will have the {urn:ietf:params:xml:ns:caldav}calendar resourcetype mentioned above.
What types of iCalendar entities a collection can contain is then determined by the {urn:item:params:xml:ns:caldav}supported-calendar-component-set property, e.g.:
<supported-calendar-component-set xmlns="urn:ietf:params:xml:ns:caldav">
<comp name="VTODO"/>
</supported-calendar-component-set>
... in the case of the tasks collection.
You use the same property to specify the type of calendar when creating new collections on the server.
but would that mean VTODOs are not listed in any other calendar
CalDAV technically supports both styles, 'hybrid' calendars which can contain todos and events, and single-type calendars. 'hybrid' calendars will contain multiple comp elements in the supported-calendar-component-set. The iCloud server can do both styles.
Which style is preferred is largely a matter of taste. In the Apple world single-type calendars are the default, in part because Reminders and Calendar are distinct applications on iOS and on macOS. (the original MacOSX iCal app was hybrid). Also, Outlook only really supports single-type calendars.
Long story short: I would recommend to keep them distinct to avoid weird things happening :-)
/calendars/outbox/
The outbox is a legacy thing to support scheduling. A client would put meeting requests and such into this collection, and then server would fan them out on the clients behalf.
iCloud now acts as a auto-scheduling CalDAV server. In short this means that if you put a VEVENT containing ATTENDEEs etc into an iCloud calendar, it will automatically do the iTIP interactions w/ those ATTENDEEs.
Summary: just skip/ignore this.
/calendars/inbox/
This is the peer to outbox, but unlike outbox the inbox is still being used. When people invite you to a meeting/event, the inbox will contain the meeting request(s) sent by the client.
With auto-scheduling CalDAV servers this primarily serves as a way to notify the user of being invited, that is, it'll pop up in the 'Inbox' tab of the iOS Calendar, or in the notification popup on macOS Calendar.
Note that with an auto-scheduling server, the server also updates or creates matching records in the users calendars. That is, for each item in the inbox you'll find another item with the same UID in a regular calendar (unless it is a cancellation of course).
In non-autoscheduling servers with inbox support, the client is technically supposed to take the iTIP item out of the Inbox and put that into a calendar. But I don't think any client still supports this operation and I don't know servers which have an Inbox but are not auto-scheduling.
Summary: This collections contain notifications about inbox invites (as iTIP objects).
/calendars/notification/
This is similar to the Inbox, it is a collection that contains non-iTIP notifications. Its primary use is for CalDAV shared calendars. If you are invited to a calendar, this collection will contain the invitation.
