[...]
>> I totally understand that the solution I'm going to provide sounds
>> aweful, but I'd recommend to use a newer enough kernel but without that
>> check, to copy all the data to another btrfs fs.
>>  > It could be more safe than waiting for a btrfs check to repair it.
> 
> No problem for me. This report here was created for science only:-)

Thank you for your report!

It really reminds us how badly we did in the past, and gives me some
more hint on how to enhance the tree-checker to report more corruptions!

> I just wanted to your attention prior to destroying the broken FS and
> shredding potential useful data useful to track down what went wrong.
> With that now concluded I'll just do that!
> 
> But maybe one additional remark: The snapshots transferred via btrfs
> send/receive to another PC are working fine on a system using a 5.2
> kernel.

Depends on how you send.
If you are sending the subvolume alone, (without -p or -c), it only
contains data (obviously), inode mode (regular, dir, block ...)
timestamps, filenames.

No internal structures like transid/sequence included, thus send/receive
will remove the corrupted internal structures, and since the destination
is 5.2 kernel, it will recreate them using correct values.

> Since the "moved" subvolume also does not have the block
> 8645398528 I assume I don't really have to copy the files but restoring
> the subvolume with btrfs receive on a new btrfs image will also get rid
> of the errors.

No need to bother that intermediate number at all. It's completely tree
block bytenr.
You don't need to worry about tree blocks, they're just an internal
method to restore things like filenames mentioned above.

As long as the important part is the received correctly, there is
nothing you'd ever need to bother, as they are all *internal* used data
structures, only kernel and developers need to care (and in this case,
receive side kernel will handle it, even developer don't need to care).

Thanks,
Qu

> 
> Thanks for your time, the incredible fast feedback and your help,
> 
> Alexander