Let me summarize my experience, some of the pros are:
Free and open source
Fast install and boot with no problems using default settings and the Btrfs file system that is much more robust than the outdated FAT32 format in ROS 0.4.9. Gone are the days of waiting for checkdisk after a crash.
Compatible with some Windows drivers and apps (trial and error so far)
Basics like screen, keyboard, TrackPoint, DVD work fine
Ethernet is working now but required some hands on magic to activate the drivers without crashing the OS (and I forgot the exact steps that it took me)
App-manager is included with a range of free preselected and compatible Windows apps just like in Linux (requires Internet)
Some apps that worked: 7zip, Wordpad, Excel viewer, CPU-Z, Firefox 48, Opera, Opensonic, SimCity 3000, Pingus, etc.
I believe the system stability has been improved over the previous version 0.4.9 because I did not get any OS crashes expect for incompatible drivers
Some of the negatives are:
USB is still not working (USB storage, mouse, etc) but there exists a patch with USB support that should be added into the main releases in the future
Sound is not working (Windows drivers don’t work)
Generic video drivers are slow and support no advanced features
Sometimes slow an unstable, mostly depending on the apps
Interesting video.
Do the BTRFS tools get installed when you choose BTRFS as the FS?
BTRFS cannot handle dynamic databases or files so the qcow2 HD has to be a fixed size, NOT dynamic if BTRFS is to run well on ReactOS.
I've been running BTRFS for almost four years. I've tried all the usual suspects for creating snapshots automatically but doing so manually is, for me, the best way. Using default settings on Snapper, for example, can create 50 or more snapshots. The devs recommend a maximum of 8 per subvolume to avoid older snapshots fully populating and eating up disk space. I usually limit the snapshot count to 4 per @ and 4 per @home. I first open a Konsole and "sudo -i" to gain root. Then I use "mount /dev/disk/bu-uuid/uuidhere /mnt" to mount the <ROOT_FS>. Ditto for my storage drive being mounted to /backup. I initially started with a snapshot of @ and @home (@yyyymmdd and @homeyyyymmdd) and after using "btrfs send ... | btrfs receive /backup" to sent them to /backup I then resort to using the incremental command to do subsequent sends to /backup:
btrfs send -p @homeyyyymmdd-1 @homeyyyymmdd | btrfs receive /backup
which results in "receive" seeing a copy of @yyyymmdd-1 on /backup and adding to it the difference between @homeyyyymmdd-1 and @homeyyyymmdd that is sent to /backup. My remote storage times dropped from 20-30 minutes per subvolume to 30-60 seconds per subvolume.
I mention all that to ask this: IF I drop to a DOS box and attempt to mount the @ or @home subvolume on another directory will it let me?
I just looked in my thread and unfortunately I can't help you with BTRFS. I do remember that after a system crash in ROS I the whole file system was magically teleported back to the last session before the crash (removing all changes from that session) so the Os is now safe against bricking it with some driver settings.