ghostscript cmyk export yields wrong black

I'm trying to convert an RGB-pdf file created by Inkscape to a print ready cmyk-pdf using PSOcoated_v3.icc color profile. PDF generation works fine. However, I'd like to check for correct final colors, especially for the black. As I did not found any (free) tool to pick the cmyk color from the final pdf I thought as a first check I convert the RGB-pdf to cmyk-tiff and check the black value. Doing so using

gs -q -dBATCH -dSAFER -dNOPAUSE \
-sDEVICE=tiff32nc \
-sDefaultRGBProfile=sRGB2014.icc \
-dOverrideICC \
-sOutputICCProfile=PSOcoated_v3.icc \
-sProcessColorModel=DeviceCMYK \
-sColorConversionStrategy=CMYK \
-sOutputFile=rgb.pdf \
 cmyk.tiff

yields a cmyk black value of [0.83, 0.67, 0.51, 0.95]. Contrarily, when I use libcms2 to convert rgb (0,0,0) to cmyk I get [0.92, 0.64, 0.45, 0.96] which matches (almost) some information about the PSOcoated_v3.icc profile I found here. To confirmed that the source RGB-file black reads (0,0,0) I convert the RGB-pdf to an RGB-tiff and do find the black to be (0,0,0).

Am I missing something in the command of might this be a gs bug?

If I take an RGB color of [0,0,0] in sRGB color space and convert it to the CMYK value defined by the PSO coated v3 ICC profile in Photoshop (using Adobe ACE CMM in Photoshop), I get exactly the CMYK values you are seeing with gs, that is [0.83, 0.67, 0.51, 0.95].

That was using a relative colorimetric rendering intent with black point compensation enabled. Those are the settings that gs would be using for lcms by default.

I suspect that when you use libcms2, it is using a different rendering intent. For example, when I use the perceptual rendering intent with Adobe ACE I get [0.90, 0.64, 0.45, 0.96].

Note that you can specify with gs what rendering intent you want to use with -dRenderIntent=0/1/2/3 . See https://ghostscript.com/doc/current/Use.htm#ICC_color_parameters for details.