Yes, I was assuming even number of sectors to simplify things. Otherwise, you got it, you have to figure out the ±1 and where it goes.

You cannot convert /dev/md/5 to LVM after the fact. In many ways LVM is similar to what I am suggesting to achieve manually here with dmsetup. It even uses the same device-mapper technology. It lets you create many logical volumes (LV) on one physical volume (PV) (I'm leaving out the middle layer, volume group (VG), for simplicity) where each LV occupies a portion of the underlying storage.

Only, it automates it and it manages the various offsets and lengths of the mappings itself in a manner you cannot control and it saves them in the volume group's metadata header so that it can reconstruct the mappings automatically and consistently. Even if you could specify the offset and size of an LV manually upon creation there is another problem.

Each LVM physical volume begins with the LVM metadata header which contains the aforementioned mapping details (as well as a volume UUID and header for autodetecting the LVM format, etc..) and there is no room at the beginning of /dev/md/5 to create that metadata because the Btrfs filesystem is already occupying that space

It would be possible to convert the whole thing to LVM using the same trick I propose: split the MD device in 2 using manually created device-mapper mappings, then create a temporary filesystem on the second half, then copy everything from the first half to the second half, then destroy the Btrfs filesystem in the first half and replace it with the new configuration you want. Then copy data back from the second half to the first half.

Then get rid of the temporary device-mapper mappings and go back to using the full /dev/md/5 only now it's got what you want in its first half. So grow that thing (which currently occupies only half the device because it was constrained by the device-mapper mapping to occupy the first half only) so that it now occupies the full /dev/md/5 device.

So unfortunately lots of steps and plenty of opportunity to make a mistake. Nothing replaces god backups!

Finally, there's another concern that I had regarding this whole thing, and it's with regards to how to make sure that the Btrfs filesystem is indeed shrunk to occupy no more than half the device BEFORE beginning any of this procedure.

Btrfs supports multi-device filesystems (that's one of its greatest features: filesystem-aware CoW replication or parity storage has many advantages over traditional RAID with a filesystem on top) and I was wondering how the btrfs fi resize command for resizing Btrfs filesystems deals with that: does it resize the whole filesystem? One member device only? How to make sure it was done correctly, etc...?

But I just read the btrfs manpage and it seems it's pretty clear how to do that: you specify the ID of the individual member device which you would like to resize when using the btrfs filesystem resize command. You'd definitely want to double check with btrfs fi show to see that the device had indeed been shrunk before proceeding.

FINAL CONCLUSION: there's lots and lots to be careful about as evidenced by the number of works I just finished writing about it (whew!) but it certainly can be done. Be very, very careful and you have to understand what's going on at each and every step. I have experience with this kind of thing and still I would be reluctant to attempt it without good backups.