Looks like this case also always results in undecorated names.

x86_64 code can still use "vectorcall" convention

The linked MS doc says "Note that in a 64-bit environment, functions are not decorated.", apparently it applies to vectorcall too?
Raw-dylib didn't attempt to support vector call yet, so I don't know what is the correct behavior there.

That's an inaccurate statement, it should rather say that functions are not decorated by default. Vector call is still a separate calling convention on x64 however, and is still decorated (https://docs.microsoft.com/en-us/cpp/cpp/vectorcall?view=msvc-170, https://godbolt.org/z/asdbdzePz)

Vector call is still a separate calling convention on x64

Yeah, I was aware of that, but wasn't sure about the decoration.
Just checked it with Visual Studio's C compiler, and looks like it's indeed the only calling convention that is decorated on x64.

Filed MicrosoftDocs/cpp-docs#3854

Ha, I didn't even know this stuff is in open source now.

I've seen this logic elsewhere, it's split into fn i686_decorated_name and fn i686_arg_list_size as a part of implementation of the raw-dylib feature.

Could you make sure these two implementations do the same thing?
fn i686_decorated_name, for example, adds or not adds underscore depending on the mingw flag.
(Ideally the code would be shared, but not necessarily in this PR.)

I just checked that the current behaviour in i686_decorated_name to not add _ in MinGW is due to the fact that it uses dlltool to create a library, and i686 dlltool will automatically add _ to symbols if it does not start with @. For the generated object files we need to add _ ourselves.

There are no other behavioural differences.