This makes a numerous amounts of incorrect assumptions.
For one it assumes all sRGB monitors utilize gamma2.2 for decoding images. This is bluntly put, completely wrong. A large amount of displays utilize the inverse OETF (the peicewise srgb transform) for decoding sRGB. (for some more information from a somewhat authoritative body, filmlight's "srgb we need to talk" video on youtube goes more indepth but TLDR is 25-50% of displays use the inverse sRGB oetf)
this is why windows HDR uses the inverse oetf. Decoding content graded on a pure 2.2 display with the inverse oetf is way better then decoding content graded on an inverse oetf display with a pure 2.2. Windows took the safe route of making sure most content looks at least OK. I would not say that windows HDR is wrong, it's not right, but it's not wrong either. this is just the mess that sRGB gave us.
Another time you should be using the inverse sRGB OETF to linearize content when the original content was encoded using the sRGB oetf and you want to go back to that working data, but this applies less to compositors and more to authoring workflows.
Another wrong assumption
When you use Windows 11 on a desktop monitor and enable HDR, you get an “SDR content brightness” slider in the settings - treating HDR content as something completely separate that’s somehow independent of the viewing environment, and that you cannot adjust the brightness of. With laptop displays however, you get a normal brightness slider, which applies to both SDR and HDR content.
People have been adjusting monitor brightness for ages. Sometimes manually, sometimes with DDC etc.
Another issue that is brought up is "graphics white" BT.2408 is a suggestion, not a hard coded spec, many different specs or suggestions use a different "graphics white" value. A good example of this is JXL. 2408 also very explicitly says 'The signal level of “HDR Reference White” is not directly related to the signal level of SDR “peak white”.'
this is important to note because this directly contradicts the some of the seemingly core assumptions made in the article, and even some of the bullet points like "a reference luminance, also known as HDR reference white, graphics white or SDR white" and "SDR things, like user interfaces in games, should use the reference luminance too"
if your application has some need to differentiate between “SDR” and “HDR” displays (to change the buffer format for example), you can do so by checking if the maximum mastering luminance is greater than the reference luminance
This needs to be expanded upon that this does NOT correlate to what the general user understands HDR and SDR to be. HDR and SDR in the terms of video content is no more then a marketing term and without context it can be hard to define what it is, However it is abundantly clear from this quote here that how they are interpreting HDR and SDR (which is a very valid technically inclined way of interpreting it) does NOT fall inline with general user expectation.
Anyone reading this article should be made aware of this.
I should elaborate on why the "Peak white" stuff is wrong, they give this math here for mapping linear luminance. This can be really confusing, "what do we map the references to" well if PQ "graphics white" is 203, should we map sRGB to 203? clearly not, at least not always as implied by BT.2408.
the question as to what we map SDR content to in an HDR space is complex, and in many cases almost certainly not some number that we can do 1:1 mapping with, which is why specifications for inverse tonemapping exist. for instance BT.2446 defines multiple tone mapping algorithms to go from SDR->HDR->SDR or HDR->SDR->HDR or any step inbetween with minimal content loss and fidelity loss.
we cannot do a simple one size fits all function and expect everything to be hunky dory