I still have the file system from a linux host I installed in 1999 or 2000. Debian; I made a VM copy when I retired the iron. It doesn't have a.out shared libraries, so even if the kernel's support worked in 2000, I could't run that binary for lack of shared libraries.
If the kernel's support hasn't really been tested for 19-20 years and the shared libraries haven't even been built, then I think running that binary has very poor chances of working.
Now, if you agree that shared libraries haven't been available for a long time and that coredumps haven't worked for a long time, that doesn't mean that nothing works. That doesn't mean that every case has been broken. But I think it means that the support has been very lightly tested for a long time now, or not tested at all. And assuming that something works when it hasn't been tested for a long time is ugh.
I think the reason I care about this is dogmatic. I believe, dogmatically, that untested code is broken. If you accept that dogma and do not test a.out support now, then the coming change does not break a.out. If you do test, fine. If you disagree that untested code is broken, fine. If you say it "might imaginably work" or somesuch, fine.
a.out is a very old format superseded by ELF.
I would like to ask who's idea it was to name GCCs default output after a completely different file format ?!
So the command-line arguments and defaults are older than the ELF format. When ELF support was added, the question was: Should the default value for -o depend on other arguments? There didn't seem to be good reason to have a complicated default, and keeping the simple default provided compatibility with old scripts and makefiles.
cd tests ; for a in *.c ; do gcc $a && ./a.out ; done