As far as I know, fasmg differs in that the symbol table can be dynamic, which got me thinking "How does fasm1 get away with a static symbol table?".
test.asm

results

I think that is a bug in fasm, c.x shouldn't exist, b.x should exist.

The only thing that I can say is possibly a bug in fasm1 here is that it failed to report that it's static analysis was insufficient, and therefore went on to produce something unexpected.

It's been a bug (IMO) forever in fasm. It isn't fixable in its current form.

It happens because the label names are produced by the preprocessor stage, so "if 0" isn't considered at that stage, and "c" becomes the new base label for following labels. By the time the assembler stage runs the label name "c.x" has already been produced, and the information about it being created in the "if 0" block has been lost.

Note that label names (produced by the preprocessor stage) are separate from the values defined for them by the assembler stage.

fasm actually has another stage between the preprocessor and the assembler, it is the parser stage. See this description from 2003, and also this clarification from 2004. In short, the parser converts the preprocessed source into a bytecode that is then executed by the assembler repeatedly in a multi-pass process. Directive handlers and opcode generators are the "instructions" in this bytecode, and labels are converted to references (which are, in fact, direct pointers to the memory reserved for symbol structure).

This separation of stages was the architectural choice that allowed fasm to be fast, but I too recognized it as an architectural flaw, which is why my design for fasm2 (and its engine, fasmg) assumed no separate stages at the price of performance.

BTW, fasm's parser could in fact determine that "c:" label in your example could not be processed, because it detects when IF condition does not depend on any assembly-time variables. It optimizes such IF/ELSE blocks by discarding the condition and the code which would never be assembled. However I made it still process the labels in the discarded block, to make the behavior consistent. Therefore you can rely on IF having no effect on label naming in fasm - while it is a flaw, at least it is predictable.