Your point of view is quite narrow and in the same time you are exceptionally rude and insinuating person. Especially being moderator - it seems you have to read basic forum rules by yourselves.
IMHO it was allowed since your statement was also awfully narrow. You can't make such sweeping statements without expecting some pushback.
Using unstable software tools with sensitive security applications, you playing with other lives and money.
Nearly no software tool allows to blindly pass on claims from users to compiler creator. IOW in a critical situation, you will have to do your own testing to guard against claims. If you don't do that, THEN you are playing with lives and money. So unstable or stable are arbitrary labels.
Of course validating a simple language might be easier, so for the
most critical software only compilers that implement a relative straight dialect are used (nowadays usually C but 15-20 years ago, there was still quite some Modula2 usage), to aid validation. That this is not always true, is proven by the continued usage of Cobol :-)
FPC/Lazarus are tools for fun and learn, nothing else. Over many decades is proven that each new "stable" version brings new bugs and regression. Who is fine with FPC/Lazarus is for them.
So is nearly any other tool. There are no guarantees. Validate a compiler, and then keep using it, is the only sane way.
Payed commercial tools are no different, including Delphi, unless they are much more stable. I have personally bought one license only of suited target model, used to the version IDE quirks, fixed bugs in RTL and VCL, used proven third-party libraries/components, made my own I needed and used all while it was suitable. It was only serious RAD at the time on the market.
Never ever updated with newer version, if old worked correctly. If updated any, every single project had to check extensively before actually make it permanently.
Delphi is riddled with bugs and traps too. YOu just learn to live with it. Which is why if you need to make a move for some reason, you need to discover the new ones of a new version (and even more so, since Delphi has quite large jumps)
My point was that if there is a reevaluation, it isn't always needed to exclude tools based on pretty arbitrary labels.
Indeed, the comments here are so naive here, that indicates only that the person which comment it never being professional programmer. Pathetic...
For embedded work, we mostly use Microchip. I'm currently evaluating moving from the old C30 compiler to the new
er XC16 compiler, mostly because newer chips aren't supported by C30.
I'm having problems (a SPI bus init that looks good doesn't work anymore , while mirrored code for a different bus just before does work, so it seems possibly place/timing related), but I haven't drilled down yet. We do use NOPs to avoid raising the CS too early, so the compiler might deal with those differently.
So in short, I'm doing
currently exactly what I was talking about, in a professional enviroment. Evaluating compilers. (there is no FPC backend for dspic btw). Admittedly, the goal is not medicin, and there won't be that many dead people when the lamp on a beerbottle inspection machine dies. But beerbreweries and their bottle makers are big business, so it is not home automation either.
But a development engineer at Phillips Medical happens to be a neighbour, and we often confer about embedded matters.
There are many gradations in medical security, but also many changes to challenges. Nowadays they are increasingly moving to other embedded chips for new products because they must be (more) mobile (read battery powered and thus lowpower) and use different wireless interfaces. Preferably with options to do simple data transfer (e.g. from sensor to bluetooth) without waking up the core by connecting dma operations. This is mostly newer chip functionality.
Of course absolutely crucial lifesupport is wired and uses ancient software and tools that never change, but not much development is done with that either.
But these wireless products are commonly used in hospitals (though less so on the lifesupport/trauma departments). Phillips is of course less bound by tool cost due to their size, and won't select on tool price, but they do check on part functionality out of a wide portfolio, and have the ability to have parts customized, and therefore sometimes must migrate a line to a new chip/architecture and thus compiler.
Any idiot can dish out industry truths from embedded magazines, but the craft is carefully weighing options based on conditions, risks, time and availability.