Other Odd GELI behavior if setkey -n 1 is used on root FS during boot: pwd rejected 4 times

I already asked this in PR 206600 but got no reply till now. This is a very generic thing and I am wondering that I shall be the first stepping in. I going to move over from Debian to FreeBSD because ZFSonLinux drives me mad with systemd boot but at least I trusted LUKS/dm-crypt...

The conditions:
I have a FreeBSD installation in a VMWarePlayer created with installer-dvd 10.2.
zpool status shows a root-pool in /dev/da0p4.eli => encrypted blockdevice and a bootpool

It's all result of FreeBSD's "auto zfs root" installation with encryption flag set to "yes"... that is what FreeBSD defines as baseline for ZFS. I have not played around with manual activities (mainly because the installer's navigation is buggy).

I define an additional pwd in slot 1, while slot 0 is used from geli init:
System reboots normal and is rejecting the new pwd (which very short and simple and very independent from default us-keyboardlayout => asdfg).
It asks first generically for geli pwd... later 3 times explicitly for /dev/da0pa4 while counting down "free tries". At the end it asks for /gpz/zfs0.eli pwd and is booting with asdfg string as pwd.

After reboot zpool status shows the rootpool to be located at /gpt/zfs0.eli not /dev/da0p4 any more.

Steps to reproduce this:
- Adding a new password in slot 1 is successful with:
root# geli setkey -n 1 /dev/da0p4
[...blabla] may exist old metadata in /var/backups [...blabla]
root# reboot

Some tests I made:
- Using initial pwd from init "qwert" works still fine and I can start system with one keyboard action: qwert-Enter.

- Using setkey -n 0 will overwrite first key successfully but will end up in rejecting this pwd 4 times later again...

- A non-root ZFS in a geli container behaves like the it should.. I can create a da1p1.eli and change password by using geli setkey -n 1 /dev/da1p1...
=> It has to do with ongoing boot process maybe sdout is pushed to pwd as well?

Any ideas?