Looking at a screenshot I took on a MacBook Pro with Retina display and running OS X 10.11, I found that it contained these chunks:
IHDR, iCCP, pHYs, iTXt, iDOT, IDAT…, IEND
All of these are part of the 2003 spec, except for iDOT which is a small (28 bytes) chunk. According to the chunk naming conventions, the fact that its second letter is capital should indicate that it's a chunk with a public specification. I couldn't find its specification anywhere yet though. It's not listed in the Register of public PNG chunks and keywords, Version 1.4.6 either, although that appears to be the latest version.
There are many sites on the web mentioning that chunk, including many on Stack Overflow. Most are describing error messages along the lines of
ImageIO: PNG invalid PNG file: iDOT doesn't point to valid IDAT chunk
and those which got resolved found out some kind of image corruption not neccessarily due to this chunk, or applied some conversion which presumably also deleted this chunk.
Many pages also mention Retina displays. It is my guess and hope that this chunk somehow indicates the display density in effect when the screenshot was taken. That would be massively useful for automatic scaling of screenshots.
Edit: Taking some more screenshots, I find that indeed the pixel density seems to play a part: running the display at native resolution I get no such chunk and the image dimensions as shown while taking the screenshot. Only at higher density do I get the chunk and a PNG image size which is an integer multiple of the displayed one. The 28 bytes of data seem to represent 7 little-endian 32-bit integers. For me these were (2, 0, h, 40, h, h, x) where 2 presumably indicates the pixel density, h is the apparent image height (i.e. half the one actually stored) and x is some number I don't understand at all. I don't know how fractional pixel densities would enter this game.
Where can one find details and perhaps even a specification for this chunk? Do I have to contact Apple or the registry, or is there someone here who can provide more details?
As Hendrik already wrote in a comment, https://www.hackerfactor.com/blog/index.php?/archives/895-Connecting-the-iDOTs.html has reverse-engineered the purpose of this chunk. It contains an offset to a well-defined position in the encoded image data. Right after a flush so decompressor state is reset, and also right at an IDAT chunk boundary, and with a known pixel position at half the height of the image.
The purpose of that is to allow decoding the image data in parallel on multi-core processors. This goal has recently (2021-12-01) been confirmed in a comment on that page from someone involved with the implementation. That comment, albeit still far from official, is there most authoritative I could find on this issue so far.