No exclusion, certainly, but how would you instruct the parser as to what to store in each buffer? It needs some way to segregate headers, and scripts, to do what DD is suggesting.
I'm not even keen on disabling it by default. I can think of three separate ways to handle adding this feature without in any way impacting the existing operation of the import directive. ( I've separately posted all three in the thread.)
Thus far, a few suers have also asked for simultaneous support, and I don't know of any reason that we couldn't simultaneously support both modes of this. This allows users to adapt to, and shift to the new paradigm, without the fear of any older scripts ever breaking from the change. It also permits the most stubborn users to fall back on the present import method. Deprecating it slowly wouldn't really work, because that's the same outcome as disabling it now, and the user will always find old scripts that they want to use, which may rely on the old operation.
There are still users, right now, downloading, and using scripts from 2007-8. ... You know how fun it is to support that nonsense.
We can't support converting existing scripts from a dev end.
Beyond that, if a user mixes and matches scripts that work with the standard 2.5 import scheme, and new scripts, say, that come out after we did something like this that are designed to use this scheme, those would not get along together if the option is a boolean setting of new/old import method.
OTOH, If you use a parser directive token, or if you used a different directive token than import, then you can shift modes on the fly... That's another compelling reason to simultaneously support both, as otherwise you will create script incompatibility due to users mixing syntax generations, which would be bad. (-Cue Harold Ramis impression).