Related problem

Hook closures provide no input args in most cases, extensively limiting existing hooks functionality.

This issue got immediately apparent in both cases where I tried to utilize hooks.

First case is, I would like to pipe any command help (--help, -h) output through | bat -lcmd-help. To achieve this, apart from hacks maybe, one needs access to the output stream in some way.
I would expect the display_output to specify the output in a variable for use within the hook closure so that it provides the ability to inspect the output and act accordingly within the hook.

Second case, I came up with a hack to be able to reload the source of custom defined commands without the need to have the shell instantiate, and I've been exploring a way to integrate it within a hook so that it always re-sources the command being run which allows for quicker iteration on custom functions when developing them. Again, I would expect some information being available in the hook closure, in particular the name of the command to be executed, maybe the entire pipeline which user has typed in the commandline before pressing return.

Describe the solution you'd like

To sum up in some type of perhaps more encompassing proposition for fixing the issue:

Have some kind of default argument passed in applicable hooks, which would provide information relative to a typical "complete", which will include, stdout, stdin, command/script in execution, working dir of invocation, commandline, and exit_code to name a few which will likely enable quite an array of new functionalities which were out of reach previously.

Describe alternatives you've considered

Tried hacking my way around the lack of supplied information, but that's rather futile. I'm quite sure this limitation is something that I'll come to face in almost every case when trying to utilize a hook, as it has been the case both of times in my rather short history with nushell.

Additional context and details

Unless I'm missing something major, in my humble opinion this functionality ought to be included as a central component in every hook out of the gate, as the lack thereof renders the largest portion of possible use-cases infeasible and to a large degree defeats the purpose of hooks times when there is no defacto way of referring to the respective output within display_output, or the command about to be executed within pre_execution and limited the scope of the hook to just a way to hook code in parts of the execution chain rather than encompassing the closure with the information necessary to perform any kind of meaningful action based on context.