diff --git a/docs/btrfs-other.md b/docs/btrfs-other.md
index 3b5982b..6546d87 100644
--- a/docs/btrfs-other.md
+++ b/docs/btrfs-other.md
@@ -11,28 +11,37 @@ bees has been tested in combination with the following:
 * Concurrent file modification (e.g. PostgreSQL and sqlite databases, build daemons)
 * all btrfs RAID profiles
 * IO errors during dedupe (read errors will throw exceptions, bees will catch them and skip over the affected extent)
-* Filesystems mounted *with* the flushoncommit option (system crashes, power failures OK)
+* Filesystems mounted *with* the flushoncommit option ([lots of harmless kernel log warnings on 4.15 and later](btrfs-kernel.md))
+* Filesystems mounted *without* the flushoncommit option
 * 4K filesystem data block size / clone alignment
-* 64-bit and 32-bit host CPUs (amd64, x86, arm)
+* 64-bit and 32-bit LE host CPUs (amd64, x86, arm)
 * Huge files (>1TB--although Btrfs performance on such files isn't great in general)
 * filesystems up to 30T+ bytes, 100M+ files
 * btrfs receive
 * btrfs nodatacow/nodatasum inode attribute or mount option (bees skips all nodatasum files)
 * open(O_DIRECT) (seems to work as well--or as poorly--with bees as with any other btrfs feature)
+* lvmcache:  no problems observed in testing with recent kernels or reported by users in the last year.
 
 Bad Btrfs Feature Interactions
 ------------------------------
 
 bees has been tested in combination with the following, and various problems are known:
 
-* bcache, lvmcache:  **severe (filesystem-destroying) metadata corruption
-  issues** observed in testing and reported by users, apparently only when
-  used with bees.  Plain SSD and HDD seem to be OK.
+* bcache:  no data-losing problems observed in testing with recent kernels
+  or reported by users in the last year.  Some issues observed with
+  bcache interacting badly with some SSD models' firmware, but so far
+  this only causes temporary loss of service, not filesystem damage.
+  This behavior does not seem to be specific to bees (ordinary filesystem
+  tests with rsync and snapshots will reproduce it), but it does prevent
+  any significant testing of bees on bcache.
+
 * btrfs send:  there are bugs in `btrfs send` that can be triggered by bees.
-  The [`--workaround-btrfs-send` option](options.md) works around this issue,
-  but possibly at great cost.
+  The [`--workaround-btrfs-send` option](options.md) works around this issue
+  by preventing bees from modifying read-only snapshots.
+
 * btrfs qgroups:  very slow, sometimes hangs...and it's even worse when
   bees is running.
+
 * btrfs autodefrag mount option:  hangs and high CPU usage problems
   reported by users.  bees cannot distinguish autodefrag activity from
   normal filesystem activity and will likely try to undo the autodefrag
@@ -49,4 +58,5 @@ bees has not been tested with the following, and undesirable interactions may oc
 * btrfs out-of-tree kernel patches (e.g. in-kernel dedupe or encryption)
 * btrfs-convert from ext2/3/4 (never tested, might run out of space or ignore significant portions of the filesystem due to sanity checks)
 * btrfs mixed block groups (don't know a reason why it would *not* work, but never tested)
-* Filesystems mounted *without* the flushoncommit option (don't know the data integrity impact of crashes during dedupe writes vs. ordinary writes)
+* flashcache: an out-of-tree cache-HDD-on-SSD block layer helper.
+* Host CPUs with exotic page sizes, alignment requirements, or endianness (ppc, alpha, sparc, strongarm, s390, mips, m68k...)