Originally raised by John Bowler on the email list:

I would also like to see some discussion of the issue raised by the now
well established ACES AP0 profile. It is described here:
https://acescentral.com/knowledge-base-2/aces-working-spaces. Because one
of the AP0 end-points has a negative y the colour space can't be
represented in cHRM. There is also no support in cICP (fixing this raises
a boatload of issues.)

The specification of the cHRM chunk is, currently, that it only allows
unsigned values for the 4 chromaticities however the encoding supports
signed values as well (the encoding is a 32 bit encoding, unsigned values
only use 31 bits). As I've said simply extending the definition to allow
signed values; changing the word "unsigned" to "signed" at the relevant
place in the cHRM specification, does not invalidate any existing PNG cHRM
chunks and, while initially only applicable to ACES and other, similar,
workflows is easy to accommodate in all PNG implementations that I've seen
(perhaps some already do through lack of checking!)

Subsequent email thread