[Unintended Feature|Bug] creating nested directories from collection names

Hi, this is a set of unusual behaviors and since i'm not super familiar with the code figured it might be best to explain the whole situation here rather than try to guess at what parts are unintended and discuss it first, before creating new issues to separate and track the bugs (if necessary)

I was reviewing my vdirsyncer configuration file with the intent of cleaning up my sync pairs and adding some new calendars i created on my CalDAV server. while doing this i got tired of dealing with the UUIDs and came across the section of the configuration docs that explain how to sync a collection that is named different locally than on the remote. That section of the docs also explained why the displayname isn't used for calendar identification (which totally makes sense). that left me thinking that as long as whatever the name of the local version of the collection is unique, what i call it in the config file could match the displayname property. With that I tried out adding a collection entry that looked like this:

[pair fastmail]
a = fastmail_calendar_local
b = fastmail_calendar_remote
collections = [ ["Personal", "Personal", "...-...-...-..."], "etc." ]
conflict_resolution = "b wins"
metadata = ["color", "displayname"]

[storage fastmail_calendar_local]
type = "filesystem"
path = "~/Calendars/fastmail"
fileext = ".ics"

[storage fastmail_calendar_remote]
type = "caldav"
url = "https://caldav.fastmail.com"
username.fetch = ...
password.fetch = ...

While doing this, i hadn't noticed the part of the docs that said that the second value in this 3-value sequence was supposed to match a storage entry, so invoking vdirsyncer sync <name of pair> didn't work, but invoking without the pair name argument: vdirsyncer sync caused the "Personal" (second-value) to be assumed as a sub-directory off the pair.a storage (resolves as ~/Calendars/fastmail/Personal/). This resulted in a directory named "Personal" being created to house that calendar's ics files, instead of the directory being named after the UUID name of the collection. In my mind, this was fantastic as it made interacting with the calendars much easier as they had human-readable names now.

Since that was a success, I tried expanding on this behavior; which ultimately lead to some bugs. At this point i was looking at the vdirsyncer configuration docs alongside the khal configuration docs to see how to make things holistically "better" (more manageable). It was at this point I tried adding a / to the local collection's name. I made a guess that the / would be interpreted as part of the name but mechanically cause a sub-directory to be created and the ics files to be placed within. I knew that this might be entering the realm of undefined behavior, but gave it a try regardless -- and it seems to work normally for the most part. The only issue I've encountered so far is that running the discover command will prompt you every time as it seems like vdirsyncer the application interprets these names as literals, thus in the collection's storage path, an item with the name of Prefix/Suffix (or Prefix/Suffix/Suffix/Suffix/Suffix/etc.) doesn't exist, as it will only find Prefix. However, the implementation details of this are such that it does successfully create the desired sub-directory that the name would resolve to, and place the defined metadata and all ics files in that sub-directory, thus making it a vdir. (see https://github.com/pimutils/khal/issues/864 to see a diagram of the whole sync directory tree)

At this point I thought that the discover command behavior was odd and re-read the docs only to then find the part that explains that if you use this behavior of using different collection names, you also have to define a storage entry for it, and that this naming scheme i was using was not within the scope of defined behavior.

So, at this point I'm looking for a bit of clarity as to:

1. is what I'm doing a defined behavior?
   a. if not, can it be?

2. if i were to add storage entries for each of my local collections:
   a. does this become defined behavior?
   b. or is the / in names still make it undefined?

3. (tangential) is there a way to make defining the collections property of a pair more readable? I attempted all this because trying to determine the contents of each when only using UUIDs was a pain. using the method of different remote/local collection names does increase the read-ability, however being able to define this over multiple lines would be better.

Version: vdirsyncer, version 0.16.7
System: Ubuntu 16.04.6 running in WSL environment
CalDAV Server: Fastmail

Start with the configuration documentation for pair collections and storage entries, then reproduce the described behavior with the sync and discover commands using collection names containing /. Determine whether nested directory creation and repeated discovery prompts are defined behavior, and document the intended result and any needed separation of the reported questions.