The command line like

> soffice.exe --convert-to pdf path-to-file.odt --outdir c:\test\
or
> soffice.exe --convert-to pdf --outdir c:\test\ path-to-file.odt


fails to produce the output file in the specified directory; while

> soffice.exe --convert-to pdf path-to-file.odt --outdir c:\test

works fine (note the trailing backslash in the outdir path in the first case). Also

> soffice.exe --convert-to pdf path-to-file.odt --outdir c:/test/

works.

The problem is that soffice.exe processes its command line arguments, and passes them to the spawned soffice.bin process quoted in double-quotes; it appends -env:OOO_CWD=... to the end of the resulting command line. So, the resulting soffice.bin command line in the first case would be

> "soffice.bin" "--convert-to" "pdf" "path-to-file.odt" "--outdir" "c:\test\" "-env:OOO_CWD=2C:\\Users\\username"

This command line is later processed in osl_createCommandArgs_Impl using CommandLineToArgvW, to split it to individual arguments. But the latter WinAPI function processes the sequence \" (backslash+doublequote) specially, i.e., in this case it treats this as escaped doublequote, inserting the unescaped doublequote into the resulting argument, instead of treating the doublequote as limiting the argument. So the part

> "c:\test\" "-env:OOO_CWD=2C:\\Users\\username"

is converted into one resulting argument

> c:\test" -env:OOO_CWD=2C:\\Users\\username

instead of expected two arguments:

> c:\test\
> -env:OOO_CWD=2C:\\Users\\username

which causes the error trying to write to a non-existing directory with a doublequote in the middle.

The described behavior is discussed in https://docs.microsoft.com/en-us/windows/desktop/api/shellapi/nf-shellapi-commandlinetoargvw.

Tested with Version: 6.1.2.1 (x64)
Build ID: 65905a128db06ba48db947242809d14d3f9a93fe
CPU threads: 12; OS: Windows 10.0; UI render: default; 
Locale: ru-RU (ru_RU); Calc: group threaded

and with LibreOffice 3.4.0 
OOO340m1 (Build:11)