Regarding SQL Versions and restore to older versions: the "assuming no new keywords are used" would be a bad sign for a new version.
I don't care about all the fancy stuff that is usefull only under particular circumstances (as stretch DB, where you could offload parts of a DB to the cloud.
On the other hand we still have no LEATEST() / GREATEST() function (which should be not to hard to create, since there should be not too much difference to other functions with a varying number of parameters as CONCAT()).
Yes, we finally got STRING_AGG() with 2017, but it is very limited if you need an aggregation on different levels (you have to use several subqueries). And I'd wonder if there are developers out there, that did not curse, because it is difficult to get several columns PIVOT()ed (without dirty tricks as concating / splitting the values into a long string). Okay, I may be wrong, PIVOT is not the best known feature, so some of us may not have used it...
I hope MS will put some more focus on T-SQL and help us with our daily work.
On the other hand you'll still need real version numbers, otherwise it may become hard to make code switches for functions added only in newer versions (and I doubt, that everybody would install a new feature update immediately, so you'll still need it).
Regarding the restores on older servers: as long there are no big changes to the data storage layout (e.g. after implementing ColumnStore or InMemoryTables), I see no reason, why it should not be possible to restore to an older SQL version server. Yes, some procedures / functions / views may become invalid, but this should be no show stopper. Nor should any new system tables / views / functions / columns be a problem.
God is real, unless declared integer.