As I mentioned in a comment on the cargo schema RFC, I think that epochs and version numbers are two distinct things. That is, you may want to upgrade to a specific rust version number because of a bug fix, or to get access to some library routines. You may do this even though your code is still "old epoch" code.
In other words, it is not just a "marketing gimmick" (as you suggested earlier) to mark an epoch separately from a release number -- there is a real technical distinction being drawn here. The rust compiler is still in the 1.X release because older code works just fine, without changes. If we called the new epoch 2.X, it might lead you to think that you cannot upgrade your compiler to Rust 2.1 just because you haven't converted your library to the new epoch yet (but that would not be true).
(Nonetheless, you could imagine using version numbers for both the rustc release and epochs. For example, iirc, Java's compiler allows you to compiler older code with a
--version flag (e.g., if you use
enum as an identifier, you would compile with
--version 1.4 or something). There would still be two distinct concepts, presumably, but both would be versioned with a semver: the compiler in use and the "compile as of" version. The concern here is that this will give the impression of incompatibility where none exists; I am not sure if this is true or not!)