No, we do not generate the PDBs during the build as we cannot distribute them currently. Packaging them into the installer is not really viable (it would add ~20+ GB to the installer), we would need to do an online installer for that and that requires additional infrastructure that we do not currently have. The online installer would allow you to opt-in to downloading the symbols and fetch the ones that you are interested in (at the granularity of the MSI). Ideally, setting up a symbol server would allow us to properly distribute the PDBs with the granularity of whatever is actually required for debugging.
No you don't. You just need a separate download, e.g. a zip, that one would look for if and when they need it. PDBs don't need to be installed. They only need to be obtained.
The logistics of offering a 20GB ZIP file for every toolchain build require some thought. You donât want users downloading ZIP files to find the one that matches their toolchain by trial and errorâit wastes usersâ time and costs the Swift project money. An HTTP symbol server probably makes the most sense, but would require custom tooling since the SymStore.exe tool is rather naĂŻve. It would also require client configuration until someone adds a call to SymSetSearchPath to the Windows builds, and verifies that debuggers correctly pick up on this.
Sure, but then that requires even more work to organize the storage and mapping for the releases. By using the installer we donât have to figure out the storage organization by including it in the insoles. Also note that this is how the PDB distribution works for Python 
Only for the 2.7 releases, apparently. Not for the 3.x releases. Still, if it works for them...
P.S. SPM apparently builds with dwarf rather than PDB by default (Thwarting WinDbg in the process). I'll have to figure out how to override this.
You can do swift build -debug-info-format codeview if you would like CodeView and PDBs to be generated. The defaulting to DWARF is to ensure that the default experience of VSCode with the Swift extension is ideal - LLDB really needs DWARF to be useful for debugging Swift and this ensures that debugging within VSCode works as expected.
VSCode uses DWARF? I would expect a Microsoft tool to use CodeView.
At the very least, WinDbg uses CodeView. I suppose I can use an LLDB frontend instead. Not that it makes for much of a difference, given that none of my own code is loaded during the stuck shutdown, and Foundation contains neither DWARF nor CodeView.
Addendum: While the Foundation stuck location is unreliable without a PDB, the calling ntdll method seems more reliable. It seems FlsFree is where things get stuck. It keeps on looping and looping through it, but never exiting. This is likely indirectly calling Foundation through its deallocation callback. And I recon it's somewhere in there that things go wrong (e.g. It's trying to recreate the FLS despite the process trying to exit, leading to an infinite loop).