@marcov
You would have to rewrite the entire parser, and redesign the whole dialect. Possible, but not trivial.
This is a very patient and informative response to the OPs question.
I don't know if you are one of Lazarus' developers, but I'm going to take a blind guess and say you are (?).
No. I work on Free Pascal, and mostly in libraries, not the language. But I learned a thing or two about language (and language discussion) over the years. Note this is mostly my opinion, but some parts (like C syntax having been suggested many times and categorically rejected) are facts.
The adding of random borrowings from other languages to official FPC is
extremely unlikely, see the mentioned faq item. Pure syntax rearrangements need not apply, since they only complicate and expand the dialect. Even if you would agree that a random syntax B is better than current syntax A (and usually we don't), having them BOTH (you need to keep A out of backwards compatibility) is even worse than having only the lesser one of them.
And no, having a compiler switch or dialect mode doesn't fix that, just look at the strange objfpc-Delphi mode split that is an artefact of such discussions that still persists 20 years later. In time it will only mean that the FPC codebases will become (even more) a patchwork of styles and dialects. That is more likely to send a newbie running for the hills than clean, Pascal syntax.
I would expect interesting solutions that might get a level further on the feature selection path to be more in the direction of co-routines/m*n light threading, maybe tuples and multiple returns from functions in general. But even those need to be embedded in a framework to make a chance. A feature in isolation is rarely worth the trouble.
So no tired old 1970's C syntax, which has been proposed already roughly three times an year since 2000 and been roundly rejected every time.. Usually also paired with the same old transparent reason of "familiarity for newbies", while the net difference only covers the first half of the first page of a tutorial book. (and you can't even skip that half page entirely since the resulting hybrid would be subtly different anyway)
Most other arguments seem to be self-evident in nature and not particularly critical of the C block syntax in the first place (and concepts like Dangling else are over their head). And even C++ follows Modula2+Pascal by introducing a modular structure, only 40 years late.
And then there is the killer problem. Who is going to implement it? This is even a problem for an accepted solution, but even more for a controversial one (since even if you can show it to somewhat work, it might not be accepted).
There is no tin of developers that are just waiting for inspiration. Most devels have todo lists that keep them busy even after retirement.
It is nice that you are keeping in mind that most people who request a feature have absolutely no experience whatsoever in developing a parser or compiler. Even as long as I've been programming, I wouldn't pretend to know where to begin with customizing Free Pascal to my preferences, and I'm guessing (I could very easily be wrong here) the original poster wouldn't either. So, it is nice to see that you politely point out how much work it would take to implement his request rather than the often seen response given by others which equates to "Your feature request is stupid because we don't want it. Now go away!."
Well, above you have a verbose "stupid etc" bit.
However, the semicolon bit was different because it hadn't come up (seriously) before, and I misjudged the initial impact on the parser. It was way larger than I initially thought (thanks to Mark and Thaddy for discussing it). Initially I thought it would be solvable locally, e.g. just fixing the ELSE statements (e.g. by forcing always a block), but the straw that broke the camel's back is behaviour with incorrect code. You would really have to redo the most basic level of the scanner/parser.
And if you want to make/suggest language suggestions, you need to start playing with parser software or write your own one, so you can predict effects better. And when doing that it is important to persist, and implement the language as designed, and don't let the parser architecture (tool or handcrafted RD) tempt you in solving it the easy way. Then you very swiftly discover that implementing undetailed features that don't align with the language philosophy is hard, very hard.