Lightroom: Add 10-bit/channel color display support

So on Windows LR truncates the 16-bit PPRGB to 8-bit PPRGB then transforms to 8-bit "Monitor RGB"?    Isn't this non-optimal and will lead to unnecessary banding and posterization?

If I was converting color spaces in Photoshop from 16-bit PPRB to an 8-bit narrower monitor colorspace, I'd transform to the monitor colorspace while still in 16-bit then truncate to the monitor color-depth.

Is this non-optimal transform being done for speed purposes or because the GPU can't do the transform in 16-bit?  Or am I wrong that the order of the color-space conversion and bit-depth-conversion makes a difference?

This answer is less specific than the previous one, so let me be clear about what I'm saying, and yes it is about the conversion of the 16-bit ProPhotoRGB colorspace to the 8-bit monitor colorspace of Windows which would be close to either AdobeRGB for wide-gamut monitors or sRGB for non-wide-gamut monitors, and neither is as wide as ProPhotoRGB.

It was the particular ordering of the color-space conversion and the 16-bit to 8-bit truncation that seemed wrong to me.  Let me explain in more detail so there is no confusion:

If I was doing the 16-bit ProPhotoRGB to 8-bit monitor-RGB in PS I would do it in two steps:

1)  16-bit ProPhotoRGB (64K colors per RGB channel) to 16-bit sRGB (for example) 64K minus the colors out of gamut which is less but still many more than 256 colors per channel).

2)  16-bit sRGB to 8-bit sRGB - 256 colors per channel

Now if from what you said happens in the CPU computations of internal LR colors to monitor colors, this is the order:

1)  16-bit ProPhotoRGB (64K colors per RGB channel) to 8-bit ProPhotoRGB (256 colors per RGB channel).

2)  8-bit ProPhotoRGB (256 colors per RGB channel) to 8-bit sRGB (256 colors per RGB channel minus the out-of-gamut colors for sRGB, so less than 256 colors per RGB channel).

So in the optimal way we get 256 colors per each of the three RGB channels.

And in the non-optimal way we get less then 256 colors per channel--only the colors left after the PPRGB colors that are out-of-gamut in sRGB are thrown away. 

Each level in each channel leads to a band on the screen.  In a smooth gradient such as the sky, those bands are visible.  With less than 256-colors per RGB channel there are fewer bands and they are more prominent.

So my question is, why is this non-optimal conversion of 16-bit PPRGB to 8-bit monitor-RGB being done?   Or is the analysis of it being non-optimal for the colors-per-channel not right, or is the interpretation of what you said happens not right and the ordering is actually the optimal ordering--colorspace conversion occurs in 16-bits in both the GPU and CPU and then the CPU conversion truncates to 8-bits afterwards?
---
As an appendix, here is a real-world example comparing the number of colors in a document converted optimally and non-optimally from 16-bit ProPhotoRGB to 8-bit sRGB. 

To create this example document, I drag-sized the PS color-palette to maybe 1/6th of the screen, then did a screenshot, copy-pasted that screenshot into a PS document, converted to 16-bits, assigned my monitor profile, converted to ProPhotoRGB, bi-linear resampled up to 1024x1024 pixels, g-blurred it by 8-pixels, increased the saturation by 20, g-blurred it by 8-pixel radius again, resulting in the starting document with the following properties:

1024x1024 dimensions = 1048576 total pixels, 1045410 total colors as counted by this plug-in: http://telegraphics.com.au/sw/product/CountColours

If I convert optimally from 16-bit PPRGB to 16-bit sRGB then to 8-bits there are 305598 colors.

If I convert non-optimally from 16-bit PPRGB to 8-bits then convert to sRGB there are 165603 colors, which is a bit more than half as many colors compared to doing it the optimal way.

I had dithering turned off for the ProPhotoRGB to sRGB color profile conversion assuming this is what happens when converting to the monitor profile via the CPU to make it faster.  If not then please enlighten me.