The 'fv' switches are not being honored with the 'emp' input boxes for some keystrokes processed from the buffer, the way the 'v' is honored for those buffered keystrokes in the other button-only forms.
If the 'v' and/or 'f' switches are used, it should be impossible for the $input() box to return $null, except if returning the empty content of the edit/pass/dropdown box. And that's true for the following 3 examples if you wait the 2 seconds before interacting with the $input() box. But pressing <enter> during the 2 seconds freeze returns $null for all 3 templates:
//var %end $ticksqpc + 2000 | while ($ticksqpc < %end) noop | echo -a : $input(prompt,pfnv,title,default)
//var %end $ticksqpc + 2000 | while ($ticksqpc < %end) noop | echo -a : $input(prompt,mfnv,title,default,a,b,c,default)
//var %end $ticksqpc + 2000 | while ($ticksqpc < %end) noop | echo -a : $input(prompt,efnv,title,default)
'm' and 'p' return the expected return value from finding <esc> in the buffer, but 'e' returns $null instead of the expected $cancel or $false
'p' also has quirks related to <tab> in the buffer. 'e' returns $no due to the changed button focus if the buffer contains <tab><tab><enter>, where pressing <spacebar> is interchangeable with <enter>, and 'm' does the same for the equivalent <tab><enter/spacebar>.
But 'p' has different behaviors for these keystrokes coming from the buffer. <tab><tab><enter> always returns $null regardless of how many <tabs> precede the buffered <enter>, while 1-or-more <tab> preceding the buffered <spacebar> does not recognize the focus moving to a different button, and instead inputs a space character into the password box.
'p' also does not handle <shift+tab> the same way as the other $input forms, where it cycles focus through the buttons in reverse order. However, for the 'p' form, once the focus reaches either the passbox or the eye-con, <shift+tab> will only toggle the focus back and forth between these last 2.
