ZFS send/receive fails, target has been modified, because of a zfs userspace query?

I use zfs send/receive to replicate a zfs file system to another server every day. The workflow is the standard send receive:

# 1. create snapshot on source
zfs snapshot ${source_fs}@${today}
# 2. send incremental update from yesterday to today to target
zfs send -i ${one_day_ago} ${source_fs}@${today} | ssh user@${target_host} "zfs receive ${target_fs}"
# 3. destroy old snapshots from two days ago on source and target
zfs destroy ${source_fs}@${two_days_ago}
ssh user@${target_host} "sudo zfs destroy ${target_fs}@${two_days_ago}"

This worked fine for a while. However, now I get this error from zfs receive:

cannot receive incremental stream: destination pool/filesystem has been modified since most recent snapshot

zfs list -t snapshot on the target shows a small value in the USED column of the most recent snapshot (something around 100K). This should be zero. The file system isn't mounted on the target.

I have a script that checks zpools and zfs quotas. The query of the current quotas (with zfs userspace $filesystem -pH -o name,used,quota -s used) seems to be what modifies the filesystem. Is this to be expected? I don't get why a query of some numbers modifies the filesystem.

I use Ubuntu 20.04 with OpenZFS 0.8.3 from the Ubuntu repositories.

Unmounted zfs filesystems cannot be modified by anything except receive/destroy and .... (well, that's pretty much all) requests. Any zfs requests about filesystem statistics shouldn't modify the fs contents. So, concluding, I highly boubt that zfs userspace is modifying something (and I doubt your zfs datasets are unmounted). But if I'm wrong (about zfs userspace) - this is clearly a bug, and a huge one.