No, it was too late at night and I was unclear. Here is a better description, I hope.
Over time I did snapshot the 18.04.3 Xubuntu dataset manually. During the standard GUI upgrade from 18.04.3 to 19.04 in that clean-up step I agreed to delete all unused old binaries. I think, you should delete the 18.04.3 snapshots too in that clean-up step, since they are useless afterwards. You can’t roll back anymore, since the old 18.04.3 environment has been largely deleted. For the “do-release-upgrade -d” there is no clean up step, so there the problem does not exist. For the future GUI upgrades you should have to reconsider the clean-up step and its relation to the previous snapshots of the dataset of the operating system.
I restored the access to my 2 zfs-Ubuntus, by fiddling with /boot/grub/grub.cfg and explicitly pointing to the Linux 5.2 images and rerunning “update-grub” afterwards in the ZFS based Xubuntu 19.10/Linux 5.2. I will have to clean-up my systems now. Running update-grub in Linux 5.0 does not detect anything related to /etc/grub.d/10_linux_zfs and in Linux 5.0 I need to fallback to my old 40_custom. Another user might run into the same issue, if he rolls back to linux 5.0 and tries to update-grub from there to repair the 5.2 boot process.
Some of my issues are related to the transition to zfs booting, so maybe you should not solve them in the system, but in the release notes with a clear description, how to circumvent them.