Forgive me for the name of the issue but it will soon become clear, another heading could have been "how not to test the build system".

I was looking for an example of HDRRULE and the only thing I found was test/core_dependencies.py. I figured out how it worked, but when I tried to extract a Jamfile from the test, I only got errors.
And if you want to experiment for yourself, just use the following Jamroot (which is a simplified version)

DEPENDS all : c ;
HDRSCAN on c = (.*) ;
HDRRULE on c = hdrrule ;
rule hdrrule
{
 ECHO $(<) $(>) ;
}

write anything in a "c" file and then

# echo hello > c
# b2
(no frame):ERROR: rule "hdrrule" unknown in root module.

But how is it possible then that the test works?

Well, in short, here's what the test does (you can do it too):

# b2 -fJamroot
c hello
...found 2 targets...

Just use the -f option, and the script magically works!

Test code in core_dependencies.py use the interpreter with the -f- argument to pass a script to the process's standard input, but it is not uncommon to use the -f option with any file argument in tests.
This issue heading is now clear, but what happens is not.
For that, look at the implementation of the guarded_main(int argc, char * argv[]) function in jam.cpp:

 ...
 /* Load build system. */
 if (args_data.files_to_parse.empty())
 {
 FRAME frame;
 frame_init(&frame);
 /* Initialize the native API bindings. */
 b2::jam::bind_jam(&frame);
 /* Launch the bootstrap to load up the build system. */
 status = b2::startup::bootstrap(&frame) ? 0 : 13;
 }
 /* Parse ruleset. */
 if (!args_data.files_to_parse.empty())
 {
 FRAME frame;
 frame_init(&frame);
 for (const std::string & s : args_data.files_to_parse)
 {
 b2::value_ref filename(s);
 parse_file(filename, &frame);
 }
 }

And now it should be clear why the test using -f is not running the build system!
Tests often give a false sense of security, but insecurity is guaranteed when the context in which a test is executed is very different from the context of real use.

Now there are 2 things left to do:

1. Fix this HDRRULE bug
2. Use the -f option with caution in testing