False. BTRFS is the default file system for the cache drive because the system allows you to easily expand from a single cache drive to be a multiple device pool. If you're only running a single cache drive (and have no immediate plans to upgrade to a multi-device pool), XFS is the "recommended" filesystem by many users (including myself)
The docker image required CoW because docker required it. Think of the image akin to mounting an ISO image on your Windows box. The image was always formatted as BTRFS, regardless of the underlying filesystem. IE: You can store that image file on XFS, BTRFS, ReiserFS, or via UD ZFS, NTFS etc.
More or less true. As said, you've always been able to have an XFS cache drive and the image stored on it.
The reason for the slightly different mounting options for an image is to reduce the unnecessary amount of writes to the docker.img file. There won't be a big difference (AFAIK) if you choose a docker image formatted as btrfs or XFS.
But, as I understand it any write to a loopback (ie: image file) is always going to incur extra IO to the underlying filesystem by its very nature. Using a folder instead of an image completely removes those excess writes.
You can choose to store the folder on either a BTRFS device or an XFS device. The system will consume the same amount of space on either, because docker via overlay2 will properly handle duplicated layers etc between containers when it's on an XFS device.
BTRFS as the docker.img file does have some problems. If it fills up to 100%, the it doesn't recover very gracefully, and usually requires a delete of the image and then recreating it and reinstalling your containers (a quick and painless procedure)
IMO, choosing a folder for the storage lowers my aggravation level in the forum because by it's nature, there is no real limit to the size that it takes (up to the size of the cache drive), so the recurring issues of "image filling up" for some users will disappear. (And as a side note, this is how the system was originally designed in the very early 6.0 betas)
There are just a couple of caveats with the folder method which is detailed in the OP (my quoted text).
Cache only share. Simply referencing /mnt/cache/someShare/someFolder/ within the GUI isn't good enough.
Ideally within its own separate share (not necessary, but decreases the possibility of ever running new perms against the share)
The limitations on this first revision of the GUI supporting folders, that doesn't make how you do it exactly intuitive. Will get improved by the next rev though.
Get over the fact that you can't view or modify any of the files (not that you ever need to) within the folder via SMB. Just don't export it so that it doesn't drive your OCD nuts.
There is also still some glitches in the GUI when you use the folder method. Notably, while you can stop the docker service, you cannot re-enable it via the GUI (Settings - docker). (You have to edit the docker.cfg file and reenable the service there, and then stop / start the array)