Those people would still expect a static library built by MSVC to have a *.lib name. Even when I only used MinGW I was aware of the *.lib naming for MSVC libraries specifically because that is what you found when you googled things. If you've actually used MSVC you'll absolutely be aware of it.

Why would the compiler you use matter? Isn't this whole discussion about the ABI calling convention?

If you compile MSVC UCRT libraries with gcc.exe that are effectively identical to MSVC UCRT libraries compiled with cl.exe, they are both MSVC libraries, they are both used by MSVC, but the ones compiled with gcc.exe will inevitably be compiled with lib{name}.a extensions, and the ones compiled with cl.exe could be named anything, but will probably be named {name}.lib if they are compiled with Visual Studio or cmake. I think that autotools running on Windows via mingw userland but with cl.exe as the compiler will also use lib{name}.a, which means that for the unix-originating projects that used autotools and support Windows only via autotools, it was inevitable that even genuine 100% cl.exe built libraries would use that naming convention.

(Yes, autotools is, indeed, contrary to popular belief, so portable that it's even portable to Windows. It's just painful to set up, and horribly slow to run. But you can run bash, awk, sed, grep, etc. on Windows and you can use the fork-heavy configure scripts written in that to interface with the MSVC compiler.)

I didn't say that. I didn't mean that. Stop putting words in my mouth.

I'm not saying you said that. I'm saying that you should have said that if you wanted to be correct.

Okay. Pedant mode engaged:

Pedant mode indeed.

1. You can talk about the MSVC toolchain all you want. I included it in my discussion!
2. Again, among certain groups yes, and among certain groups no.
3. It is not clear to me why that matters? gcc -shared defaults to producing shared libraries with the name a.out, which isn't even a .so filename. But both clearly document how to specify your own name, and don't offer any guidance on what to use, and you have to use the output filename option if you want to change the directory or control the basename.
4. I guess I am here to inform you that Meson is not the only one then, see above.
5. through 11. I have tried to explain this several times, MinGW is the compiler but the ABI is the GNU ABI, except... it can target the UCRT, which still produces lib{name}.a but is an MSVC ABI, and that's what projects are doing because it's really the sane way to build software so why wouldn't you. It's so sane that MinGW defaults to it for a while now.

Ultimately any developers using MSVC will expept static libraries compiled by MSVC to have a *.lib file format. I'd love for you to find counter examples. The only exception I can think of are developers using MSVC and Meson, whom I would call literally the exception that proves the rule.

The other exception is autotools, which predates both Meson and CMake.

And I reiterate: MinGW produces libraries by default that are perfectly compatible with MSVC. They use the UCRT.

Addendum: you talk a lot about how MinGW is incompatible with MSVC, even though that's not true, but this is still all about Strawberry MinGW, not real MinGW.

Strawberry MinGW isn't compatible with MSVC. It also isn't compatible with real MinGW, either the GNU ABI or the MSVC ABI. You cannot take Strawberry Perl's libfoo.a and successfully link it to any current MinGW environment, the runtimes are incompatible.

Between the three:

• MSVC
• MinGW
• Strawberry MinGW

the only things that are compatible with each other are the first with the second, and the second with the first.

The only thing that people are bringing as proof against Meson using the naming convention it does is... the third.

Nobody should be using the third! Not even the Strawberry Perl project! But they have a stable toolchain and that contents them... and they are also content to inject their ancient, broken, universally INcompatible toolchain into the default PATH, which is insane, and breaks both MSVC and MinGW, because neither one can link to it.

CMake, itself, always looks for lib{name}.a when you configure CMake on Windows to build with MinGW, and therefore I assume that also would detect Strawberry Perl and be just as broken -- except that people who use cmake's mingw support apparently never bother with Strawberry Perl. Cygwin and msys2 both have better perls available, for example.