Is that not just "adaptive gamut" or whatever it's called — where a display capable of HDR (like the recent miniLED-driven iPad displays) will still be driven with an SDR signal most of the time to save power (as SDR content has a lower contrast ratio, and so is less demanding of peak brightness), but will switch into HDR mode when displaying HDR content (and so "desaturate" — i.e. bring down the black level, lowering the seeming contrast level for darker content — in order to display bright lights as really really white)?
It's maybe strange that compositing HDR + SDR together results in SDR rather than HDR, of course. You might consider that to be the bug.
But I could see that being an intentional choice by Apple (though one that's maybe not thought out in the context of an iPad-as-consumption-device.)
In most situations where you're staring at a composited HDR+SDR signal for a long time — e.g. a video editor editing an HDR video timeline/preview, inside an otherwise-SDR UI — the SDR content exists both before the HDR content is opened, continues to exist after it closes, and takes up the majority of the screen. So you don't want the SDR content changing its gamut just because some HDR content shows up. You want the HDR content to be squashed down to SDR for preview. If you want to check how the video looks in HDR, you'll preview the video fullscreen for a bit. (Or, if you want to always be seeing the video in HDR, then you'll use a dedicated second display that the video is always fullscreen on — as any color-grading software expects you to do.)
The scrubber widget being composited on top of HDR content is an exception to this, of course. That widget should be brought into HDR, not the other way around. But maybe this is a very low-level compositor thing, that's hard for something all the way up at the app level to signal down to to say "hey, don't mind me, we're watching a fullscreen video up here, just make me HDR!"
It's maybe strange that compositing HDR + SDR together results in SDR rather than HDR, of course. You might consider that to be the bug.
But I could see that being an intentional choice by Apple (though one that's maybe not thought out in the context of an iPad-as-consumption-device.)
In most situations where you're staring at a composited HDR+SDR signal for a long time — e.g. a video editor editing an HDR video timeline/preview, inside an otherwise-SDR UI — the SDR content exists both before the HDR content is opened, continues to exist after it closes, and takes up the majority of the screen. So you don't want the SDR content changing its gamut just because some HDR content shows up. You want the HDR content to be squashed down to SDR for preview. If you want to check how the video looks in HDR, you'll preview the video fullscreen for a bit. (Or, if you want to always be seeing the video in HDR, then you'll use a dedicated second display that the video is always fullscreen on — as any color-grading software expects you to do.)
The scrubber widget being composited on top of HDR content is an exception to this, of course. That widget should be brought into HDR, not the other way around. But maybe this is a very low-level compositor thing, that's hard for something all the way up at the app level to signal down to to say "hey, don't mind me, we're watching a fullscreen video up here, just make me HDR!"