Sushimasta: This would totally break the use of import. Import is meant to seperate the code into own "worlds" and does not know of "higher level" stuff to which it is linked at a later date. This is very elemental and important for modular OO design, that you can fully encapsulate code and guarantee that its variable scopes do not intersect.
Your idea would totally break that as it would break the guaranteed scopes to retrieve data for the outer world it is not meant to even know. (wouldn't even want to know how you plan to make precompiled modules work with your approach)
The only thing currently missing in BM are prototypes, that would remove any need of cyclic import (thats the way C++ gets around the problem as well).
that part sadly has to be faked through abstract classes with a later implementation ...
Your idea would totally break that as it would break the guaranteed scopes to retrieve data for the outer world it is not meant to even know. (wouldn't even want to know how you plan to make precompiled modules work with your approach)
The only thing currently missing in BM are prototypes, that would remove any need of cyclic import (thats the way C++ gets around the problem as well).
that part sadly has to be faked through abstract classes with a later implementation ...