> It doesn't work this way. The snapshots a and b are not based on the
> same underlying subvolume. The gist is that you would keep changing A,
> and take additional snapshots of A, such as a.1 a.2 a.3, and you can
> do incremental send with 'btrfs send -p a.1 a.2' which describes the
> difference between those two snapshots of A at their respective
> moments in time. You could also do 'btrfs send -p a.2 a.3' or even
> 'btrfs send -p a.1 a.3'
> 
> But as there's no relationship between 

snapshots a and b, I consider
> it a bug/missing error handling feature, that btrfs send doesn't fail
> in this case. By using -p you're claiming there is a parent-child
> relationship between a and b, but there plainly isn't.

They kind of are related though, since the two snapshots reference the
same data blocks, and you can see it work in the first example with the
40MB of random data.

However, I can replicate this odd behaviour the conventional way.

btrfs sub create A
mkdir A/dir
dd if=/dev/urandom of=A/dir/server.jar bs=1024 count=40K
btrfs sub snap -r A a

cp --reflink=always A/dir/server.jar A/server.jar
rm A/dir -rf
btrfs sub snap -r A b

btrfs send -p a b > out


The out file is only 773 bytes.  However, if you repeat all those same
steps, but replace the dd with:
wget -O A/dir/server.jar
https://launcher.mojang.com/v1/objects/20c069d373e77265aaeeedb733f7051e294325a3/server.jar

The resulting out file is 34MB.