Can someone make sense out of "Hard Links and Junctions" article from MSDN?

Question

At Hard Links and Junctions MSDN article one can read the following:

A hard link is the file system representation of a file by which more than one path references a single file in the same volume. To create a hard link, use the CreateHardLink function. Any changes to that file are instantly visible to applications that access it through the hard links that reference it. However, the directory entry size and attribute information is updated only for the link through which the change was made. Note that the attributes on the file are reflected in every hard link to that file, and changes to that file's attributes propagate to all the hard links. For example if you reset the READONLY attribute on a hard link to delete that particular hard link, and there are multiple hard links to the actual file, then you will need to reset the READONLY bit on the file from one of the remaining hard links to bring the file and all remaining hard links back to the READONLY state.

Can someone make sense out of the above paragraph?
Isn't the statement attributes on the file are reflected in every hard link to that file equivalent to the statement changes to that file's attributes propagate to all the hard links?
How come resetting READONLY bit can bring the file and all remaining hard links back to the READONLY state?

EDIT

After reading JdeBP's excellent answer to this question I'm still left with doubts.

I understand there's a partial copy of MFT's $STANDARD_INFORMATION entry for each hard link pointing to this entry which according to the answer isn't even kept up to date unless a hard link is renamed, created, or destroyed. What does happen when one reads attributes of a hard link? I guess this hard link's copy of $STANDARD_INFORMATION is ignored as it might not reflect the current state and attributes are being read directly from the MFT's entry's $STANDARD_INFORMATION. Additionally during this process no information is updated as it's not any of operations you listed. Is it so?

If one sets the R bit off in order to enable deleting a hard link to the file, then (presuming that that wasn't the last link) one has to set the R bit back on again, in whatever way, to make the file read-only again.

Now, I don't get the presuming that that wasn't the last link part. I don't see how the link being the last one makes any difference here. There's still a file (MFT's entry) itself and one can change its attributes directly (not through any link). Or is it so that if there's a file there's a link meaning there's no one to one correspondence between MFT's entries and files?

Answer 1

As grawity says, the second "reset" is either poor writing or an outright mistake.

Isn't the statement attributes on the file are reflected in every hard link to that file equivalent to the statement changes to that file's attributes propagate to all the hard links?

No. The article is stating something that is perhaps too much of an implementation detail for its target readership. On NTFS, each entry in the MFT can have zero or more $FILE_NAME attributes. These record the parent directory and the name within that directory for each hard link to the file. But they also record file attribute flags, even though those flags are recorded in the MFT entry's single $STANDARD_INFORMATION attribute. The rules are a trifle complex, but briefly put $STANDARD_INFORMATION is what matters and the $FILE_NAME information isn't even kept up to date unless a hard link is renamed, created, or destroyed — which requires touching the $FILE_NAME attributes, and so is the point where the current attribute flags can be propagated to the $FILE_NAME attributes.

A developer probably explained the gory details of NTFS to the technical author who wrote the MSDN article. But they don't actually have any relevance to an end user or even to an applications programer. These are internal details of how NTFS works. From the Win32 perspective, a file/directory has exactly one set of attribute flags, and updating it is updating it, however that is done. If one sets the R bit off in order to enable deleting a hard link to the file, then (presuming that that wasn't the last link) one has to set the R bit back on again, in whatever way, to make the file read-only again.