I think the Y14.5 requires that the issue is identified on the drawing, but I don't know if Y14.100 does.
It is probably better to be explicit rather than make the recipient research what the effective contract date and the status of all related documents. While this would not be the case for many specifications, because many specifications are handled by addition of new cases without changing existing requirement or by making tolerances narrower, in the case of Y14.5 in particular there are rules changes that are contradictory from issue to issue that are only made obvious by other depictions, such as either RFS or MMC being default.
What can be especially irritating are cases that were not handled in the older versions and become explained in later versions. So, even though it was not clear to the users of the documents initially, it appears to have an interpretation.
Taking programming as an example, suppose there was a programmer who wrote FOUR = 2 + "Two" at a time when there was no conversion specified for turning "Two" into a number or "2" into text. Later, a new version language gets an interpretation that "Two" is converted to a number. At the original creation, perhaps the particular compiler would set FOUR equal to the text "2Two" or throw an error message no one noticed. The later interpretation does not fix the problem of the original document and interferes with upgrading the document by short-cutting a reasonable review.
A particular example of this came between the 1982 and 1994 versions with regards to the ability of lower segments of FCFs to refine higher segments, specifically if they applied to location and orientation or orientation alone. This problem is specifically mentioned in the foreword.
