Short answer (until I figure out a way to explain this better) is that this is an oversight (my opinion) of ZFS’s original design.
The way I work through this is by using what I call “pseudo-roots”.
You can read more about it here and from the old forums in here.
Doing so essentially allows you to better “group” and “nest” familial datasets together, such as all those sharing the same encryptionroot, in which replicating the “pseudo-root” to a backup pool will retain the same encryption/encryptionroot relationship.
However, this doesn’t overcome the issue of using the main pool’s “keys” file to unlock the datasets on the backup pool. This is because the .json file generated when you export your keys reference the name of the main pool. Hence, why you must unlock (at least once) the encryptionroot(s) on the backup pool, so that you can export the “keys” from there, which will have proper names in the .json file.
(This particular quirk is not really an issue of ZFS, but just the nature of different pools using different names. On that note, if you’ve “cleaved” the child datasets from their encryptionroot, it will also change the resultant layout of the exported .json file.)