I'm replying to both your comments together here:
You're delusional if you think ANYONE can produce bug-free software.
I normally would answer way more sarcastically than I'm going to, because I believe you misunderstood me. Notice, first, that I included a very deliberate "almost" there, so it's evident it isn't literal 100%, but as close to 100% as possible; and, second, that I wrote in a hyperbolic style, and it always surprises me when people, especially older people, who presumably had better Literature classes compared to younger folk, either don't recognize it, or show unfamiliarity with its convetions and purpose.
Which means I agree with for the most part, as I see most of your text as expanding on what I had myself reduced to a single line, rather than refuting it. But not with everything. I'm going to reply specifically to these last bits, so assume what I don't reply to I'm in agreement with.
Just like you can't possibly know if every single I-beam, that is so critical to your structure, is 100% good-to-go unless you subject every single one to X-Ray scanning or whatever the hell they use... And that'll make buildings cost too much.
I work for a civil engineering lab that applies standards published by international and national standards bodies. Those standards acknowledge that not all components of a process can be tested, but they make sure quality is kept extremely high while keeping costs manageable. Such standards exist for all engineering areas, and at the national level are enforced by national laws. They do exist for software engineering too, e.g., by ISO/IEC, but for the most part they're entirely optional, there being no legal enforcement, and the vast, vast majority of software development companies and departments with companies, not to mention individual developers, don't follow them.
In a world where software development was treated as a real engineering, following such standards would be mandatory. There would be legal requirements for audits by national accreditation agencies. Purchaseable software would need to include certificates of compliance, being otherwise forbidden from being sold. There would be paper trails showing that all components used in any purchasable software are similarly certified. If the industry wanted to use free software, it'd need to organize and bankroll accreditation for those packages before integrating them. And any unaccredited free software would only be allowed to run within highly restricted sandboxes.
For an analogy, consider how anyone who knows electronics can build, say, their own UPS, but they cannot sell it to others unless it gets UL certified and, if they plug their makeshift UPS in their wall outlet, and it causes a fire and the house burns down, the insurance company will almost definitey refuse to pay for damages, as the user willingly and deliberately plugged in non-certified device into their outlet.
Which is to say:
"this is as good as we can make it without pricing it out of most people's budget by subjecting it to insane levels of testing, verification, validation, and stress testing"
Is not how the software development industry operates. It should be the case, and I'm advocating for it to become so, but right now, with extremely few exceptions that only prove the rule, it just isn't.
You really want that world?
Yes. What you describe isn't a bad world; it's a world in which computer technology advances at a slower pace compared to ours.
There'd be disadvantages compared to ours, in that we'd likely be at something similar to, say, the late 1980s technological level right now, and wouldn't achieve what we currently have at least until the end of this century, maybe the beginning of the next.
On the flip side, there'd be advantages at the social level, with technology integrating into daily and professional life at a pace much more compatible with the way human cognition feels at home.
And it'd help with your later point:
GCC 15.x August 2025 (latest release 15.2) Current development/bug-fix release series.
In that alternative timeline, GCC 15.x would be dealing with hardware families orders of magnitude more stable and predictable. Its supported languages would be different from ours, in that all of them would have been designed to facilitate standards compliance with a goal for accreditation. Things would be so much solid that GCC's released version numbering might even follow TeX's scheme of adding digits of pi, and there'd likely be only a few digits more than TeX's current v3.141592653.
I'd like that world. But, as I said, there are many for whom it'd be Hell on Earth. I think these only have this reaction because they're used to how things are and can only see the downsides, not the upsides.
Either way, this conversation changes little. The big players will never accept being regulated and forced to follow engineering standards, and they have all the laws money can buy, so it's at best a fun speculative exercise, and little more.