I am working on one thing for sure and possibly a second thing.
The first thing, is to possibly utilize the ProgressBar Function call that Greg
Chapman talked about.
The reason to know all the information about the component/procedure at the
instance of its entry.
Especially knowing the total  number of lines  in the specific component/procedure
and the module name.

When having the total number  of lines in the component/procedure, I would then
start the call to the
ProgressBar function at 0% and knowing what the limit# is, in order to get to
100%.
Get the picture, as each component/procedure is entered.
It will cause the ProgressBar looking like a dynamically progress bar moving
back& forth all the time
until all the components/procedures are executed from start to finish in the
flow path it was executed.

Another good thing in knowing the component/procedure information at the
instance of its entry,
is also to measured the elasped time spent in each component/procedure for
performance tuning.
And, in conjunction to dynamically measure the trace flow of the VBA code  while
it is being execute.
I did this for another company, in order to fine-tune the OS and its software.
We or I did it the hard-way, by hard-coding trace-hooks data in each
component/procedure...( sigh )
From this, we could produce statistical data and reports to fine-tune the
software for optimum performance.

Last of all, the component/procedure name  is also passed to the error handler in
each component/procedure.
Sound even more interesting.