There are still major bugs in the rest of it. You can trivially corrupt a mirror. There are examples for how to reproduce it exactly in qemu with virtual drives. I caused me total dataloss on my first Btrfs filesystem at least 8 years back. That bug is apparently still there. The unbalancing issues are still there. I have zero trust of Btrfs in any form.
You (and many others) might well be using RAID1 mirrors without problems. I did as well. But the problems here are not encountered during day-to-day usage. They are bugs in the recovery codepaths following hardware failures. I suffered this due to a transient SATA cable glitch, but the instructions let you exactly reproduce this with qemu with a recent kernel. I've not tried the qemu approach myself; I moved over to ZFS a good while back now.
I've had a hunt for the specific instructions but I'm afraid I can't find it again with a search. The gist of it was to:
- create Btrfs mirror using two qemu virtual disks
- pull the (virtual) plug on one of the pair to disconnect it, then later reconnect it
- Btrfs ends up hosing both the outdated and current copies of the mirror, leading to complete dataloss of the entire mirror
Whatever voodoo they are pulling out of thin air, is clearly not present on commodity, non-tuned Btrfs filesystems. That, and most people have backups set up on their NAS.
Well, if you want, you can just pull the drives out of your Synology box and hook them up to any Linux system [1]. So whichever way they're tuning it, it can't be that voodoo-esque.
According to them (https://btrfs.wiki.kernel.org/index.php/Status) only RAID56 is unstable.