Why should it not be used automatically in case the source snapshot no longer exists? In the end, as far as I understand, zfs send doesn’t care where it gets the snapshot metadata from. It mainly needs the TXG and GUID to generate an incremental stream.
I just confirmed it in the ZFS source.
Call stack:
zfs_do_send(CLI - cmd/zfs/zfs_main.c:4780@8f6f4bc),- calls:
zfs_send_one(libzfs - lib/libzfs/libzfs_sendrecv.c:2877@8f6f4bc), - spawns in new thread:
zfs_send_one_cb(libzfs - lib/libzfs/libzfs_sendrecv.c:2869@8f6f4bc), - ultimately calling:
lzc_send_redacted(libzfs - lib/libzfs_core/libzfs_core.c:819@8f6f4bc), - ultimately spawns in new thread:
lzc_send_resume_redacted_cb(libzfs - lib/libzfs_core/libzfs_core.c:892@8f6f4bc), - ultimately calls kernel with ioctl:
zfs_ioc_send_new(kernel module - module/zfs/zfs_ioctl.c:7236@8f6f4bc), - calling:
dmu_send(kernel module - module/zfs/dmu_send.c:2781@8f6f4bc), - where the bookmark metadata is extracted from a snapshot, or simply loaded from the given bookmark into local variable
zfs_bookmark_phys_t *zb(kernel module - module/zfs/dmu_send.c:2904-2994@8f6f4bc)
So even if given a snapshot it just extracts the same metadata the corresponding bookmark would hold. I don’t see a reason not to fall back to a bookmark.
The only hindrance could be that zfs send -R does not yet support bookmarks as you pointed out in your explanatory post. I’m not sure whether TrueNAS uses the -R option internally or whether they iterate the children datasets manually.