The whole point of this thread is to meet a company's requirement for a submitted media work.  So on that level, you would need your rendering agent capable of outputting whatever their requirement is.  Even if, like you say, you weren't typically making or distributing at that higher bit depth.  With audio, hell, I'd even prefer a simple EQ and pan in iClone itself so I wouldn't have to use an external NLE, but some prefer it.
Eh?   EH?!!!......
Anyway...:pinch:

The whole "bit depth" equation can be a bit confusing.  The 'shortcomings' we're noticing aren't completely to blame on 8 bit.  All the CGI we view, whether it's on our monitors or TV is 8 bit... and yet, most professional productions can be 'banding' or other artifacts free.  The key is the 'creation' process.  A raytrace renderer like Octane will always render in 32 bit - which is why you won't see any speed differences when 'saving' as 16 or 8 bit - operative word being 'saving'.  Octane creates a 32 bit image in it's buffers and 'saves' it to any format you like - clever algorithms work hard to maintain the integrity of the image as it's being written to a lower bit depth.  Exactly the same as the digital audio equivalent... you may record at 24 bit, but if you're making a CD it has to be 16 bit - dithering and noise shaping are needed to help control the artifacts created when reducing the resolution.  iClone supports HDR, which is 32 bit, so the "engine" is capable of feeding a raytracer to make the calculations at 32 bit.  iRay supports 16 and 32 bit output with Daz, so I'm pretty sure we'll see the same in iClone.

PNG and TIFF supports both 8 and 16 bits, OpenEXR supports 32 bits!

As far as I know, PNG only supports 8-bit, so it would require another image format. I personally wouldn't rush to 16-bit yet as it involves immense storage requirements. And unless there is a guarantee that the final distribution format supports it, it would be a waste of space, I think...:unsure:

It's a bit like a 192 KHz sample rate in audio. It makes more sense to me to introduce dithering or some such measure.

---

One thing I want to point out is that even with Iray, that doesn't guarantee iClone will have higher than 8-bit output.  They actually need to give us an option for 16-bit output.  It's a clerical-administrative matter, they need to either default it to that output depth, or give us a button that lets you select 16-bit, for example.  But if default is set to 8-bit, and no 16-bit button, then we get renders at 8-bit.
I know you know this, just mentioning that by mere fact that we say "Iray", this conceptually doesn't mean in all theoretic situations that a render is > 8-bit.

Interesting what you mention, a design choice to "save the buffer".  (LOL- when I mentioned the screenshot, I didn't mean it literally, I was using it to refer to the 'capture of data', like you are terming it here, 'saves the buffer')
And so this 'buffer' is then inflexible, like in this case it would need a 16-bit structured engine running underneath in order to save a 16-bit buffer, right?  Or, no maybe?

TonyDPrime, iClone just cant screenshot itself, if that was the case we could only render at screen resolution, which is not the case, this means that iClone saves the buffer, but it is poorly designed, as it only saves 8 bits of information, and dont forget that Octane is not a real-time engine, it is an un-biased render engine that uses GPU power, while iClone is real-time, well, sort of, but still, modern GPU save internal data in a linear way, so it is a bad design on the part of RL if iClone cant save 16 bits images IMHO!

Wildstar brings out a great point - Unity, Eevee, and UE4 all can render higher than 8-bit (16, 32) with no consequential render time impact.

With Octane, you can select 8-bit, 16-bit, or EXR, and the speed of image save upon render doesn't noticeably change, certainly render speed does not at all.
So imagine if Octane only had just the 8-bit option, that sounds that is where iClone is.  

But it sounds like maybe iClone, is by structure, unable to generate beyond 8-bit because the engine 'screenshots' itself in realtime, and in order to be realltime it has to be 8-bit.
Like,they way they have it working, they would have to re-structure the whole show, at start, to run at 16-bit, and then it thus could capture itself at 16-bit.
Hmmm...I wonder what that would look like, or what impact that would have. 
Is that Unity and UE4's visual secret, they are running the whole show at 16-bit?  Or, no, bit they do just have a mechanism of render that doesn't work how iClone's does, you know?

In any event, the Iray part now seems to go beyond a visual raytrace tool.  It becomes the de-facto 'answer' to any critique on visual.
Like-
Q - We need (X) in iClone, can we have it? 
A- Just use Iray...

Blener Eevee actually uses TAA, it also uses screen space reflections, I think iClone mainly uses probes, either way, same goes for me, no rendering in iClone, but its still is a great tool for character animation!

Eevee Roadmap

unity, unreal , eevee, all this engines export with 32 bit color space.  and just to rememember 
unity and unreal use TAA in realtime,at any resolution you can render in 8k if you want with 32 bit color space. and is not secs per frame. its frames per sec so how much more fast its your Hard drive more fast is the render. 
eevee use the old metod of supersampling , the same used in toolbag and iclone ( toolbag still better and fast than iclone ) supersampling is cpu based and slow. TAA is GPU based and realtime. 
this discution ends for me 2 months back. i just dont use iclone for render .. final point! *for me. but i use iclone for all other stuff like facial and body anymations
all things not related for characters i animate inside unity. and cameras animation i got a new love. cinemachine .

I just checked, Blender Eevee can export 32bits OpenEXR, damn!
I read a bit more on the Netflix guidelines, they seem to be just that, guidelines, I doubt they would refuse a movie based on the fact that it is not 16 bits!