Obviously, changing anything below examples/ cannot fix an issue in the macro files themselves, so the obviously useless patch in comment #2 was not even worth testing.  Posting patches that you already know to be wrong is not a good idea.

> I was ONLY assessing the use of the undefined variable "M#",
> nothing else as the original subject tells.

That is a serious problem right there.  Don't do that, ever.

Auditing compiler warnings is a TOOL for finding bugs.  If you are not prepared to actually inspect the code the compiler warns about in order to understand what it is trying to do and in order to judge whether it is doing that correctly and/or how it should be improved in order to reach correct results, don't bother looking at compiler warnings.  The crucial part of a fix for a compiler warning is to make sure that the code is actually doing what it intends to do.

The main goal of auditing compiler warnings is NOT to silence the warnings.  Auditing them with that objective in mind is worse than useless.  The outcome of "fixing" compiler warnings in that mindset usually is hiding existing bugs AND introducing new bugs.

That said, we still don't know how to fix the actual bug that the compiler warning revealed.

This is not the first time that i'm telling you that you keep spamming us with trivial patches without understanding what you are doing.  Even though these patches are trivial, this one is again incorrect.

Simple code inspection shows that there is an actual bug here, and your patch would only make that bug harder to find.

Consider the following test file:

some
.br
lines
.br
of
.br
text
.t*SP
.bp
one line only
.br
.t*SP
missing space before this line

Expected output should have a blank line between "one line only" and "missing space before this line".  Actual output lacks that blank line.  The reason for this bug is that contrary to the (german) comment, \n[M#] is not reset at the start of a new page.  The macro .HM mentioned in that comment doesn't even exist, it was deleted eight years ago.  But even before that, it did not reset \n[M#] - the bug is likely present since import in 2006 and was likely introduced by pre-import changes of the original authors.

It is not completely clear to me yet how to fix it.  Somehow, \n[M#] must be reset to zero when a new page starts.  The same bug might affect columnated text as well, so it may also need resetting at the start of a new column.

The low code quality of the hdtbl macros is really annoying, they are buggy as hell, and the missing initializations are the least among the problems.