Pkg3: correcting invalid version compatibility claims

As pointed out in JuliaLang#3 (comment), it is not always possible to fix broken compatibility claims by tagging new versions.

Pkg3.md

@@ -145,7 +145,13 @@ Expressing compatibility between various versions of packages is complicated by
 
 Pkg2 allows and even encourages very loose dependency declarations and deals with both of the above situations by allowing compatibility claims to be adjusted after the fact. Dependencies can and are expected to be changed in METADATA to adjust for mistakes and invalidation. This causes significant complexity and confusion, however: the dependencies of a package version according to its own immutable source may not match the current dependencies registered for it in METADATA – which are still potentially evolving. Because of this, Pkg2 contains tricky logic about which compatibility claims take precedence – those in the source tree or those in METADATA. These rules are especially complicated since Pkg2 supports development of packages where they are installed, further muddying what the definitive record of compatibility is.
 
-In Pkg3, a package version's compatibility claims are immutable. While compatibility claims may still be incorrect, they cannot be changed, only superseded by a newer version. Overly broad compatibility claims cannot, by design, be expressed in the first place. In this design, any invalidation of claimed compatibility can only stem from another package's failure to follow [semantic versioning](http://semver.org/) correctly. However, since this will certainly occur in practice, when it does, it can easily be remedied by a new release of either package. Instead of modifying compatibility claims after the fact, if a version's claims are found to be mistaken, one publishes a patch, with the same major and minor version numbers, with corrected dependencies. Pkg3's version resolution will favor the most recent patch very strongly: unless you explicitly ask for an earlier patch specifically, a freshly installed or updated package will always be the latest patch in its major-minor series. Package developers should follow semantic versioning strictly and *only* include bug fixes in patch releases: patches should neither break existing features nor introduce new features.
+In Pkg3, a package version's compatibility claims are immutable. While compatibility claims may still be incorrect, they cannot be changed, only superseded by a newer version. Overly broad compatibility claims cannot, by design, be expressed in the first place. In this design, any invalidation of claimed compatibility can only stem from another package's failure to follow [semantic versioning](http://semver.org/) correctly. 
+
+However, since this will certainly occur in practice, there will need to be a mechanism to remedy it:
+
+ * If the compatibility claims were too restrictive, a new patch with wider version compatibility ranges can be published. Pkg3's version resolution will favor the most recent patch very strongly: unless you explicitly ask for an earlier patch specifically, a freshly installed or updated package will always be the latest patch in its major-minor series. Package developers should follow semantic versioning strictly and *only* include bug fixes in patch releases: patches should neither break existing features nor introduce new features.
+
+ * However, if the compatibility claims were too broad, tagging a new version may not necessarily remedy the problem as the dependency resolver may decide to use the older (broken) version, in order to obtain compatibility with another package. In this case, the invalid compatibility claims will need to be revoked by the registry.
 
 Compatibility claims in Pkg3 are expressed at *exactly* minor version granularity. This may be easiest to explain starting with the textual form. In configuration files, sets of compatible versions are expressed using arrays of string literals (in TOML format), each string being of one of the following forms: