The target of a CALL or GOTO should never be inside a block statement within parentheses. It can be done, but as you see, the results are probably not going to be what you want.
The entire IF (…) ELSE (…) construct is parsed and loaded into memory before any of it is processed. In other-words, it is logically treated as one line of code. After it is parsed, CMD.EXE is expecting to resume parsing starting with the next line after the IF/ELSE construct.
After the parse phase, the complex command is executed from memory. The IF clause is processed properly and the ELSE clause is skipped properly. BUT within the IF (true) clause, you perform a GOTO :asdf, so CMD.EXE dutifly begins scanning for the label. It starts at the end of the IF/ELSE and scans to the bottom of the file, loops back to the top, and scans until it finds the label. The label happens to be within your IF clause, but the label scanner knows nothing about that detail. So when the complex command finishes executing from memory, batch processing resumes from the label instead of from the end of the complex IF/ELSE.
So at this point the batch processor sees and executes the next few lines
echo baz
) else (
echo quux
)
baz is echoed, and so is quux. But you might ask, “Why doesn’t ) else ( and/or ) generate a syntax error since they are now unbalanced and no longer parsed as part of the larger IF statement?
That is because of how ) is handled.
If there is an open ( active when ) is encountered, then the ) is processed as you would expect.
But if the parser is expecting a command and finds a ) when there is not an active open (, then the ) is ignored and all characters on the remainder of the line are ignored! Effectively the ) is now functioning as a REM statement.