...as soffice.exe creates the proper environment (PATH) for soffice.bin to be
able to load URE libs like sal3.dll, so soffice.exe itself should neither be
able to load nor depend on sal3.dll (and does not depend on anything exported by
it, anyway).

It is unclear to me how this ever worked (which it presumably did?) with any
Windows build, either native MSVC or cross-compiled MinGW.  (Maybe MSVC builds
do not record a dependency from soffice.exe to sal3.dll, noting that the former
does not import anything from the latter?)