This ism exactly what I am running with some customers.
Because of site-specific implementations for some sites I wanted to use the NO-NAT feature. Only these networks are configured for release-candidate (and some time ago "beta") while all other sites and the hubs run the stable 14.x release.
@rwiesmann we almost always run mixed versions (though mainly within a major version) and only recently for the first time in over a year did we have the same versions for about a month. We did have one issue with a 16.4 spoke and 15.42 hubs/other spokes that appeared a couple of weeks after upgrading. But that's it.
If you didn't need anymore verification already, we run a mixed versions all of the time. Our Hub is actually one of the last networks to be updated when running firmware updates within our infrastructure. This way the Hub can run on the most stable version without issue and then we can troubleshoot/test newer features on spokes that wont mess up the entire infrastructure and have to revert back.
Not to mention it is always fun to have a test/lab spoke that you can test all of the latest new beta features on 🙂
As per i saw in most of the Big organizations, Compliance team come up to always go with the version code on N or N-1. I always keep my network N-1 as it takes time to have stability on the newer version. But here yes we can mix match the various firmware like N-1, N-2 whatever we have in our production environment. I agree with @KRobert to always check the newer version on the Spoke site first and once we have stability of the version put that version across for uniformity.
Regards Inderdeep Singh www.thenetworkdna.com ( Awarded by Cisco IT Blogs award 2020)