Outputs: Logically, it seems the forward section of the macro shouldn't get processed if there are no parameters to iterate through. This was obviously an early design decision - just curious.

It is easier to exclude expressions than having to duplicate them.

Output: (No such thing as a macro without parameters if defined to take parameters.)

ORLY? Even the humble stdcall must allow for zero to infinity parameters.

But there is a parameter to iterate through... even though it has an empty value. The "y" symbol was defined in macro header, it HAS to have some value, even if empty.

Empty is good, but having no value could be a 'feature' (i.e. added confusion). "*" is used if a macro must have a value, and it's possible to pass an empty value differently than no value. It is only the present interpretation of the macro definition which limits the use - "y" is a placeholder which the present definition says defaults to empty - not undefined. Here forward/reverse have no meaning and are processed anyhow - there is no parameter to iterate through. The whole macro is common in the absence of a parameter definition. Here we have an actual empty value in "t" passed as a parameter. Yet, how is this different from "a" or "b" - which have no definition? The default definition of "a" appears to be "a". Hm...?

Not exactly. Actual parameter passed is «t» token; later is gets replaced with its value, thus conditional control directive becomes if ~eq, yet display `y is expanded as display 't'.

Preprocessed listing is priceless.

I'm trying to address the preprocessor language and not a specific programming problem.

Sorry, for being so vague.

But the substitution of symbolic variables with their values is something that you by definition (that is: by part of the language specification) get after the preprocessing, not before. Thus "t" is just what it is and is in no way empty. And if you remove the "if" in the first macro, you are going to notice that "display `y" really gets the non-empty value of "t" and thus would display "t" character.

It is related to how the language is defined, not the particular implementation.
To define such fine details of language I once wrote the Order of processing section of manual (and I plan to expand the topic in Understanding fasm). It is important that those rules really are (and have to be) a part of the language, and may still be implemented in a various ways.

Back to the original question - there is one more interesting detail.

If you had this simple macro:
you could "upgrade" it to work for multiple parameters just by putting square brackets around the "x": The "forward" behavior was originally (before there were "common", "forward" and "reverse" directives introduced) the only one, and it stayed as the default one since then.
This macro works exactly the same as the first one, unless more than one parameter is provided. This includes, that it works exactly the same as the first one when empty value for this one parameter is provided.

No, there is no "default" in present definition. You get the empty value because you provide the empty value when you use the macro. Like:
As macro is defined to take at least one parameter, it always looks for one and takes its value - even if it is empty.
This could be changed in the future to "when parameter has an empty value, the default value is taken instead", and only this way the concept of "default" could get introduced here.
And the fact that single empty parameter is in text indistinguishable from no parameters at all (which is interpretation accepted when macro is defined to take no parameters) is merely a conincidence.

They are processed as in the case of "rept 1" - you always have this one standard iteration with "macro". As opposed to "rept 0", which is not processed at all (even "common" over zero iterations is considered to be non-existing - it also requires at least one iteration to become "alive").
Note that "forward" and "common" will work this way even in case of "match" directive - when there is also an option of one iteration or zero iterations, depending on whether there is a match, or none.
This relates to the fact that those directives are universal for all macro-builders, like "macro", "rept", "irp", "irps" and "match" and they are connected to the amount of iterations specified for that macro. Even if you do "rept" without any counter, you can still create symbols to iterate through - with the "local" directive:
And there are only two ways to create zero-iterations macro - either "rept 0" or "match" with no match.

This all should get covered in "Understanding fasm", of course.