The ; in echo one; echo two is a control character. The ; in if list; then ... is part of the if syntax. They are different, not equivalent.

@Isaac, well, if this \n that \n then whatever \n fi also works, so it's not like the semicolon is a mandatory part of the syntax. As far as I can tell from the POSIX grammar, a top-level list of commands is defined with different rules than a compound_list you have inside {} or () or the parts of an if, but if there's a meaningful difference between the two in how ;/newline work, I can't tell.

But if it's { echo foo; echo bar; } vs. if something; then, then it's exactly the same compound_list in both.

@StéphaneChazelas Well, yes, there are other valid syntax(es) beside if cmd; then. I am well aware of them, as I hope you should be already aware. My point is somewhere else: .... The shell parser has a series of basic rules by which it splits a command line into words (tokens), One such rule is that a ; is a "word delimiter". We should agree up to this point. But there are some contexts that are processed by a different parser (well, technically, the same parser bound to a different set of rules). Cont. (1)

@StéphaneChazelas Cont (2) Like inside a pair of '', no ; or newline or other things are no longer special (and I used '' because it is pretty obvious what it does, but a similar argument could be built for ""). That different level of parsing also apply to the section between if and fi. That's why you can not have echo (true) while you can (perfectly valid) do if (true) then (echo true) fi (note that there are no ; and no newlines). So, the point is simply that the set of rules is different in basic parsing and in constructs like if (or while, case, for, etc.).

@StéphaneChazelas Cont (3) That is why (as basic parsing has not been suspended) not be a surprise that array=( ; a ; ; ; b ) doesn't work (as array=( a # ; ; b ) also doesn't). End (3).

@ilkkachu I am perfectly aware and clear that you are able to find a lot of corner cases to raise concern and deviate from the point raised. I won't go there. Bye.

@Isaac, FWIW, I don't think if something; then vs. if something \n then is much of a corner case, both are widely used and work. But that's neither here nor there. See you next time.

@ilkkachu We are not discussing how to replace a ; with something else. I am saying that a ; in basic parsing is not equivalent to a ; inside a if ...fi construct. Your examples just confirm that, by the way. But never mind, running in circles is never productive for anyone.

@Isaac frankly I have no idea what it is we're discussing. I tried to look how those cases are defined in the grammar, and didn't see the distinction you referred to. Also, I thought you were going to go somewhere?

@ilkkachu Exactly: You didn't see the distinction, but is your opinion the only one valid?

@ilkkachu Going somewhere? Ha, yes, I should .... :-)

@Isaac based on the grammar, no, I didn't. Sure, if you can point out which part I missed, I'd be happy to see it.

As for going, yes, you probably should, but you like arguing too much to do that, no?

@ilkkachu The one that likes arguing too much is you !

@Isaac Yes, I openly admit that if I get criticism on some technical matter, I tend to not ignore it. And if the criticism is unwarranted, or I don't immediately see where my mistake is, then yes, I do argue the matter. On the other hand, I do also accept corrections when I'm proven wrong. (I may not always like it, but I guess people seldom like being proven wrong.)

On the other hand, since you know I will argue the point, and it seems to annoy you when I do, I sometimes wonder why you bother continuing the argument for so long.

But here, sure, if you like to think of it that way, then by all means consider the semicolon in the if statement different from the one between two simple commands on the top level. They can still be both replaced with a newline, so you'll have to excuse me if I don't consider such difference very relevant, in particular wrt. the examples I wrote there.