Presently the 'trust' and 'verify_detached' commands disable all filters (e.g., verify.c:grub_cmd_trust() calls grub_file_filter_disable_all()) when opening a file containing a public key (note the distinction from verify_detached implicitly using an already-loaded key). This makes it cumbersome to construct a public key hierarchy at boot time, by loading other signed public keys. To do this securely, the author of grub.cfg would need to explicitly invoke 'verify_detached' (using an implicit public key that was embedded in core.img using "grub-mkimage --pubkey") and check the return value before invoking 'trust'.
Arguments in favor of trust respecting 'check_signatures=enforce' (i.e., making a change):
* Consistency with behavior in nearly all other file-opening scenarios when check_signatures=enforce
* Results in cleaner grub.cfg files
Arguments against (i.e., leaving things as-is):
* Desired functionality can already be obtained with appropriate script code in grub.cfg
* Makes it impossible (unless I'm missing something) to experiment with check_signatures=enforce without first providing a public key using the --pubkey option to grub-mkimage (and presumably soon grub-install).
* Most users will never look at the C code but will see grub.cfg, and it may be useful to put the public key validation logic right in front of their eyes
As I mistakenly assumed that 'trust' *did* respect 'check_signatures=enforce' upon first encountering this code, I tend to favor the position that this is the preferred functionality. I think the right way to proceed is probably: (1) fix grub-install to support --pubkey, (2) alter the behavior of 'trust' and 'verify_detached' to respect 'check_signatures=enforce', and then (3) update the documentation to make this clear.
As mentioned, the desired functionality can be obtained either way, so as I currently understand things this is more a matter of aesthetics than functionality. Note that grub.cfg files that manually validate public keys before loading them would continue to behave correctly in the face of these changes (though their validation efforts would be redundant).