Working nicely with LVM is a long term goal for Btrfs. However, Btrfs will (optionally)
maintain duplicate copies of metadata so that it can find a valid copy when it notices
checksumming errors, or errors reading from the device.
This is something LVM cannot provide because it cannot maintain consistent checksums for the
FS. Also, many admins will want to enable metadata mirroring even on single volume
filesystems where LVM isn't used.
When multiple devices are present, Btrfs will want to know it is mirroring on different
physical spindles. This is a challenge with LVM since the locations of physical extents can
change without the FS knowing about it. Even if there were hooks so the FS could know the
current extent mappings, it would end up duplicating a copy of the mappings internally.
So, the storage pool features are not trying to reimplement MD/LVM, but they are trying to
carve out the critical features that LVM cannot provide as efficiently as the FS can.
Multipathing, raid3/5 etc, dm-crypt and most of the other fun things you can do with the
storage stack are not planned Btrfs features...