Access violation in modules with MSVC

I am very eager to try out C++20 modules feature and came across an access violation at runtime. I was able to reduce it to the minimal example below. It works with clang, but runs into said av with the Microsoft compiler. It might be a compiler bug with this experimental feature, but perhaps I'm just using them wrong?
The command lines below won't produce any debug symbols. I took a look at what's going wrong with the Visual Studio debugger:

Exception thrown at 0x00007FF7222E1027 in main.exe: 0xC0000005: Access violation reading location 0x000027AB00000021.

I examined the said location in the memory view and it indeed looks like unmapped memory.

System: Windows Server 2019, x64, version 10.0.17763 Build 17763
CL compiler: Visual Studio 2019, Microsoft (R) C/C++ Optimizing Compiler Version 19.25.28612 for x64
Clang compiler: clang version 10.0.0, Target: x86_64-pc-windows-msvc

fstmod.ixx:

export module fstmod;
export struct SampleFstMod {
  SampleFstMod(const char* pData) {}
};

sndmod.ixx:

export module sndmod;
import fstmod;
export struct SampleSndMod {
  SampleSndMod(SampleFstMod name = "SampleString") {}
};

main.cxx:

import sndmod;
int main(int, const char**) {
  SampleSndMod variable;
  return 0;
}

With clang this example works:

clang++ -fmodules-ts --precompile -x c++-module sndmod.ixx -o sndmod.pcm fstmod.pcm
clang++ -fmodules-ts --precompile -fprebuilt-module-path=. -x c++-module sndmod.ixx -o sndmod.pcm
clang++ -fmodules-ts --verbose -fprebuilt-module-path=. main.cxx -o main.exe
main.exe

Translating with MSVC yields an access violation at runtime:

cl /EHsc /MDd /std:c++latest /experimental:module /c fstmod.ixx
cl /EHsc /MDd /std:c++latest /experimental:module /c sndmod.ixx
cl /EHsc /MDd /std:c++latest /experimental:module main.cxx fstmod.obj sndmod.obj
main.exe

Edit:
I'm asking:

• Why is it wrong?
  • Is it UB perhaps, because it works in clang?
• Which/where is the illegal pointer dereferencing causing the av?
• Why does it compile without warning? Once the others are answered I might find a switch enabling a warning here.

Note, I checked the disassembly and it happens when dereferencing the value of eax after a call, which is evaluating a return parameter.

This is neither wrong nor UB. It should compile just fine without warnings.
I communicated the issue with the Microsoft developers and it is indeed a compiler issue. According to them it will be fixed in 16.7 Preview 1.