TLDR: There exists a "scene referred" definition of rec2020 (and rec709) and a "display referred" definition. The current definition of rec2020 matches the inverse-OETF (scene-referred) version. I think we should use the display-referred version.

Long version:

Over in ITU-R BT.2020, in Table 4, they list the "non-linear transfer function" as $E'= 4.5E$ if $E\leq\beta$ else $\alpha E^{0.45}-(\alpha-1)$.

This transfer function is the "opto-electronic transfer function" (OETF), which transforms "scene light from a camera" to a signal (pixel value). There is footnote (4) next to it, saying:

In typical production practice the encoding function of image sources is adjusted so that the final picture has the desired look, as viewed on a reference monitor having the reference decoding function of Recommendation ITU-R BT.1886, in the reference viewing environment defined in Recommendation ITU-R BT.2035.

That is to say, the "electro-optical transfer function" (EOTF), which transforms a signal (pixel value) to "display light" should use 1886.

There's something similar in over in H.273. It defines the same OETF in the table of transfer characteristics, but in section 8.2, has the following in note 1:

In the cases of Rec. ITU-R BT.709-6 and Rec. ITU-R BT.2020-2 (as could be indicated by TransferCharacteristics equal to 1, 6, 14 or 15), although the value is defined in terms of a reference opto-electronic transfer characteristic function, a suggested corresponding reference electro-optical transfer characteristic function for flat panel displays used in HDTV studio production has been specified in Rec. ITU-R BT.1886-0.

Over in BT.1886 it defines a $\gamma=2.4$ for the EOTF.

Today, nobody does what any spec says.

• Nobody uses the inverse-OETF as an OETF, because it comes out way-way-way too bright in the dark regions.
• Nobody uses $\gamma=2.4$ as the EOTF (as 1886 would tell us to do)
• Windows and Android just treat Rec709 (and Rec2020) as having an sRGB EOTF
• Apple platforms treat it as $\gamma=1.961$ EOTF

It appears that Apple is moving to $\gamma=2.4$ EOTF in the latest beta, following the 1886 recommendation. I would be okay with moving Chromium to that (first in canvas, where values can be read back, then later for <video> element rendering, where overlays really matter).

To that end, I think it might be best to re-define rec2020 to use the $\gamma=2.4$ formulation. I'd also be in favor of adding a rec709 color space that is $\gamma=2.4$ with sRGB primaries, just to be really emphatic about things.

BTW, this is what the various transfer curves look like, compared, and mapped to sRGB values.