Open ZFS vs FreeBSD ZFS boot issues

I have a strange edge case I am trying to work around.  I have a 
customer's legacy VM which is RELENG_11 on ZFS.  There is some 
corruption that wont clear on a bunch of directories, so I want to 
re-create it from backups. I have done this many times in the past but 
this one is giving me grief. Normally I do something like this on my 
backup server (RELENG_13)

truncate -s 100G file.raw
mdconfig -f file.raw
gpart create -s gpt md0
gpart add -t freebsd-boot -s 512k md0
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 md0
gpart add -t freebsd-swap -s 2G md0
gpart add -t freebsd-zfs md0
zpool create -d -f -o altroot=/mnt2 -o feature@lz4_compress=enabled -o 
cachefile=/var/tmp/zpool.cache myZFSPool /dev/md0p3

Then zfs send -r backuppool | zfs recv myZFSPool

I can then export / import the myZFSPool without issue. I can even 
import and examine myZFSPool on the original RELENG_11 VM that is 
currently running. A checksum of all the files under /boot are 
identical.  But every time I try to boot it (KVM), it panics early

FreeBSD/x86 ZFS enabled bootstrap loader, Revision 1.1

(Tues Oct 10:24:17 EDT 2018 user@hostname)
panic: free: guard2 fail @ 0xbf153040 + 2061 from unknown:0
--> Press a key on the console to reboot <--

Through a bunch of pf rdrs and nfs mounts, I was able to do the same 
above steps on the live RELENG_11 image and do the zfs send/recv and the 
image boots up no problem.   Any ideas on how to work around this or 
what the problem might be I am running into ? The issue seems to be that 
I do the zfs recv on a RELENG_13 box. If I do the zfs recv on RELENG_11 
(which takes a LOT longer) it takes forever. zdb differences [1] below.

The kernel is r339251 11.2-STABLE.  I know this is a crazy old issue, 
but hoping to at least learn something about ZFS as a result of going 
down this rabbit hole.  I will I think just do the send|recv via a 
RELENG_11 just to get them up and running.  They dont have the $ to get 
me to upgrade it all for them and this is partly a favor to them to help 
them limp along a bit more...

     ---Mike


1 zdb live pool

ns9zroot:
     version: 5000
     name: 'livezroot'
     state: 0
     txg: 26872926
     pool_guid: 15183996218106005646
     hostid: 2054190969
     hostname: 'customer-hostname'
     com.delphix:has_per_vdev_zaps
     vdev_children: 1
     vdev_tree:
         type: 'root'
         id: 0
         guid: 15183996218106005646
         create_txg: 4
         children[0]:
             type: 'disk'
             id: 0
             guid: 15258031439924457243
             path: '/dev/vtbd0p3'
             whole_disk: 1
             metaslab_array: 256
             metaslab_shift: 32
             ashift: 12
             asize: 580889083904
             is_log: 0
             DTL: 865260
             create_txg: 4
             com.delphix:vdev_zap_leaf: 129
             com.delphix:vdev_zap_top: 130
     features_for_read:
         com.delphix:hole_birth
         com.delphix:embedded_data


MOS Configuration:
         version: 5000
         name: 'fromBackupPool'
         state: 0
         txg: 2838
         pool_guid: 1150606583960632990
         hostid: 2054190969
         hostname: 'customer-hostname'
         com.delphix:has_per_vdev_zaps
         vdev_children: 1
         vdev_tree:
             type: 'root'
             id: 0
             guid: 1150606583960632990
             create_txg: 4
             children[0]:
                 type: 'disk'
                 id: 0
                 guid: 4164348845485675975
                 path: '/dev/md0p3'
                 whole_disk: 1
                 metaslab_array: 256
                 metaslab_shift: 29
                 ashift: 12
                 asize: 105221193728
                 is_log: 0
                 create_txg: 4
                 com.delphix:vdev_zap_leaf: 129
                 com.delphix:vdev_zap_top: 130
         features_for_read:
             com.delphix:hole_birth
             com.delphix:embedded_data