Linear segment (just like in sRGB curve) only matters when you encode the picture, you will lose some black gradations otherwise. On decoding it will just be off by one. You are wrong. That math comes from 1.2 end to end gamma (illusion because of our eyes watching stuff in the dark) on back then 2.35 reference CRT, which was later changed on OLED to 2.4 gamma, because black on OLED is much darker. Math: 1.2 / 2.35 = 0.51 = 1/1.9608. Simple. Are the Apple-custom color profiles also used for encoding? Or are they only for decoding? Neither. Decoding cannot be done with OETF, while encoding cannot be done with this simple approximation. It is like you totally know nothing. ICC profiles are not for decoding, they are for color managment, that linear data will have to be further managed. Was it done for performance? No, that is what reference was before 2006, when BT.1886 got created by Sony. Was it done for compatibility with non-QuickTime-based applications? There is only mpv that supports color managment of primaries and transfer. Maybe Davinci. Doesn’t simplifying those two transfer functions defeat their purpose? No, it does not because PQ values are untouched. All color managment happens on device, for LG C9 webos does it. HLG may not stay untouchrd though, in windows only PQ can be outputed. TL:DR. You do not know what scene referred means. That means that (remember, change of primaries always happens on linear light) linear light is scene light. So OETF is used to get scene light, then you color manage, then you encode again with inverse OETF and then apply EOTF, 2.4 gamma for perfect OLED. Imgine it is LED, then gamma is 2.2, since black is bad. Imagine sunlight. Then gamma is as it was originally! 1.9. That is all just because of our vision. Next imagine absolutely black room cinema with bad projectors allowing only for 48 nits. Then gamma is 2.6.

clang now supports it. https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Clang-march-native-M1