I've been doing more testing and have narrowed it down to problems with DNxHR. When recording in ProRes, any values outside of 16-235 aren't displayed on the Ninja's screen, but are indeed saved in the recording, so behave just like in-camera recordings so no detail is lost as it can all be recovered. When recording in DNxHR however, values outside of 16-235 are lost resulting in heavy clipping. I'm not sure why this is the case - whether it's a bug, or whether DNxHR doesn't actually support 0-255 ranges or something, but they need to provide a fix of some kind, even if that's a 'remap to 16-235' setting for full range inputs.
So if you use ProRes, you're fine, if you use DNxHR and your camera can't remap to 16-235 by itself (or if you use Log) you're out of luck until Atomos fixes it (or 'if' they fix it).
There IS still a serious problem with LUTs however. No matter what, values above 235 are rendered as black, irrespective of ProRes or DNxHR, 8bit or 10bit. This is annoying for monitoring, as whites are now pure black which is distracting, but it also means you can't bake in LUTs, which is a feature I was looking forward to.
Below is a LOG recording with an almost blank LUT applied. As you can see, the highlights, which were lost as this was a DNxHR recording anyway, are just mapped to black. This is a problem even if your camera supports a limited output (16-235) as any sharpening artifacts that push past 235 are shown as black pixels. Basically this makes baked-in luts impossible, and LUT monitoring distracting. This definitely seems like a bug that they'll be able to fix however, so we'll see what they say. I've been in touch with support but have yet to hear back. Definitely try your own tests too so we can eliminate any other possible causes.