The patch level allows you to indicate when a release was bad and should be ignored (you should always use the highest patch release). With monotonic versioning an unintended breaking change must be corrected by another breaking change (breaking WRT the broken version). Now you have two breaking changes where having a patch level would allow you to correct the regression and continue with no breaking changes in the release history.
The spec encourages the following, if a bad bug is found (cough openssl):
1.1 -> 2.2 -> 3.3 -> 1.4 -> 2.5 -> 3.6
And in fact I kind of like this. 1.4 is rather obviously compatible with 1.1 (and 2.5 with 2.2), but also clearly denotes a new release. You're still always using the most recent release, within a compatibility number.
Even better, it avoids crap like: "Affected users should upgrade to OpenSSL 1.0.1g. 1.0.2 will be fixed in 1.0.2-beta2." Instead, the fix is announced simply "Bug fixed in release 4 and later".
It is confusing, but the release number is never decremented in this example, the compatibility number is being reused to indicate the release is compatible the API documentation for the existing compatibility number.
Well, in SemVer or Monotonic Versioning, if you make an unintended breaking change, say in version 2.3, you've already broken your versioning scheme anyway. So it does not really matter whether your fix (which is incompatible wrt. the broken version) is published as 2.4.
The best you can do in those situations is to advertise as publicly as possible that version 2.3 should never be used.
I believe that's what the patch number does in semver (M.m.p).
For a constant M.m, you want maximum(p) as there's potentially something wrong with any p that's less than maximum(p). Monotonic versioning seems to want to move this deprecation information to a separate channel.
