The main problem is that this solves... pretty much nothing.

You see, the real problem is not in what TC39 decides to put in or take from the specification. The real problem is that the specification is aiming for continuous evolution. And the emphasis is in continuous because that's how browsers actually implement it. Because, ultimately in the short and medium term, you're not targeting a particular version, but a set of features. Should browsers ignore your JS for the usage of, say, destructuring just because they haven't yet implemented, say, TCO?

In any case, this

That could be used anywhere a "use strict"; could be used. For example:

doesn't work at all. Let's see your example and try to figure out what it means:

function usesES8 () {
    @use @2017;
    // This is ES8
    return function () {
        @use @2016;
        // And we're back to ES7.
    }
}

So, usesES8 can only run if ES2017 is supported, right? And it returns a function which says it can run in ES2016... But what good is that? I can never get that function in ES2016. Let's see the opposite case:

function usesES7 () {
    @use @2016;
    // This is ES7
    return function () {
        @use @2017;
        // This is ES8.
    }
}

Now, I can run usesES7 in ES2016, and the result of that is a function. A function which I cannot run in ES2016.

This makes no sense;; it's not practical at all. Let's also think about the fallback. What should we do if the required version is not supported? Certainly we cannot interpret it. So in the second case, usesES7 would try to return something but we cannot interpret what that something is with our version. What should we do then? Substitute the returned function (in this particular case) for a no-op function(){}? That would certainly break any script expecting it to do whatever it is it should do. Should we simply abort the interpretation of usesES7 because some parts cannot be interpreted? That seems fairly reasonable. But then, the whole usesES7 would be a non-thing.

Back some time ago, there was actually a per tag attribute language and you could specify e.g. "javascript1.8" or putting the version=1.8 in the type; it was never really useful. In the end, the fallback will always end up being "just don't execute the script" and you simply lose that functionality. That's not what people want. If I want to run in a number of browsers, I'll need to target the common ground in all of them. And if I'm going to write a version using only ES2016, what good is writing another version of the same thing but using ES2017?