Copy/move between shares is sloooooooooooow...

Snapshots are built into btfrs at a low level, using its "copy on write" facility. Users sometimes need to delete some snapshots to manage space.

But deleting the snapshots doesn't solve the problem you are trying to solve. The shares are configured as btrfs subvolumes - that is why btrfs itself is copy/deleting. The configuration as btrfs subvolumes is what allows share by share enabling of snapshots. But the copy/delete happens even if snapshots are disabled in both shares. It's more like moving files between two drive letters on a PC. Even if the two drive letters are partitions on the same physical disk, Windows still copy/deletes if you move files from one to the other. Anyway, my setting idea upon share creation was to tell the NAS not to create the share as a subvolume at all, that instead it should create an ordinary folder.

I'm not sure I understand your question in the --reflink paragraph. The cp --reflink command tells btrfs to "clone" the file. New metadata is created which points to the data in the old file. Then the "rm" command deletes the original metadata, but since btrfs knows about the second metadata the data blocks remain allocated.

If I understand what's happening correctly, if snapshots were enabled in the two shares, then the cp --reflink has no impact at all on snapshots in either share (unless there happens to be a file with the same name already in the destination share). But the "rm" command would result in the deleted file being saved in the source snapshot.