Since there's a use case, I can work on this, although it'll be low-ish priority for now. Never knew that the Windows version of RenderDoc worked with DXVK anyway, so that's a pleasant surprise.
Please bear in mind that the conversion is not going to be entirely accurate on drivers with no native 24-bit depth buffer support (i.e. anything AMD). This is already the case when reading depth/stencil, too.
Thanks!
Probably I was too fast to say that RenderDoc just works.
Ok what works:
What does not:
So it's better than I initially expected but far from perfect.
Please bear in mind that the conversion is not going to be entirely accurate on drivers with no native 24-bit depth buffer support (i.e. anything AMD). This is already the case when reading depth/stencil, too.
It's not an issue, at least for me - anything better than crashing =)
I have return to this and made RenderdDoc open dx11 trace under wine, here is current result:

I made a mistake with what exactly tried to unmap depth-stencil from buffer to image - it was DxvkContext::updateImage, doing nothing in it when it processes depth-stencil made possible to proceed further.
All ways to upload depth-stencil data should be implemented as of 302c6b5e6c6977203b5da53c9dac11f15e0d853f.
Nothing extracted yet.
There was an issue #285 of a game that mapped a depth-stencil image to host memory, this is a symmetrical issue of unmapping it back.
It appeared when I have tried to replay d3d11 RenderDoc trace under wine and DXVK (capture went fine) - mesa's ANV driver didn't like it. The trace was of "The Witness" but I think any game with depth-stencil image would result in the same issue, games that don't have such images were replayed just fine.
In DXVK there is a packing of depth-stencil but there is no unpacking and it looks like that games themselves don't need it.
Would it be easy to implement it given that packing already works? I may try to implement it if you don't have time for this.
Software information
RenderDoc (master)