Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
The depth method most likely incorrectly limits the max depth that can be set to MAGICKCORE_QUANTUM_DEPTH. Neither the c api or magic wand api does this. Likewise the Magick::Image::modulusDepth method doesn't limit it either. Most likely the correct solution is to remove the clamping of the depth value here.
But if, or example, MAGICKCORE_QUANTUM_DEPTH is 16, what do you expect setting depth to 32 to do? It can't fill out those extra bits, because it has been compiled to store pixel value in only 16 bits.
This is mostly useful for Q16 HDRI builds where the storage type is float. By changing this you can then write 32bit float tiff files without issues. At least none that I found in my very limited testing.
To write 32-bit tiff files in Q16 HDRI, one needs to specify -define quantum:format=floating-point (in command line mode). I do not know how one does that in any API. See TIFF at http://www.imagemagick.org/script/formats.php. Other formats that support floats and negative values are: PFM, MPC and MIFF (the latter also needs the define).
If you are in Q16 HDRI compile and do not want values to exceed 16 bits, then use -clamp equivalent in your API.
If you do -compose ... -composite equivalents and do not want them automatically clamped, then use -define clamp=off equivalent.
I have one more question about the quantum:format=floating-point image attribute. Why isn't it always set when the source file is a floating point format? For example EXR images can contain it as well but it will never be set for them (I checked the source code and tried). Is this an oversight or an intentional decision for some reason?