Nested public imports - bug or feature?

[Timon Gehr via Digitalmars-d]

On 08/13/2015 06:19 PM, Dicebot wrote:
> On Thursday, 13 August 2015 at 15:59:46 UTC, Timon Gehr wrote:
>> On 08/13/2015 05:49 PM, Dicebot wrote:
>>> On Thursday, 13 August 2015 at 15:40:12 UTC, Timon Gehr wrote:
>>>> You know about static imports, right?
>>>
>>> Yes, as well as about renamed and selective ones ;)
>>>
>>> Problem with static imports is that they are all-or-nothing.
>>
>> (Which is an arbitrary restriction most likely motivated by
>> implementation difficulties.)
>
> Well I prefer to work with tools I have right now and not wait for
> something sane to be implemented.
> ...

(It's about communicating clearly what the problem actually is. static 
imports are not inherently all-or-nothing.)

>>>
>>> When doing my old "Rust vs D" comparison I have been mentioning their
>>> import semantics as a big win. When you do import like this:
>>>
>>> use phrases::english::greetings;
>>>
>>> You must always also qualify symbol name with module name like this:
>>>
>>> println!("Hello in English: {}", greetings::hello());
>>>
>>> And this won't compile:
>>>
>>> println!("Hello in English: {}", hello());
>>>
>>> It has similar benefits as the idiom proposed in this topic - greatly
>>> reduced risk of accidental clashes.
>>
>> static import greetings=phrases.english.greetings;
>>
>> ?
>
> http://forum.dlang.org/post/szaaakmavraxatkrfpnx@forum.dlang.org
>

How is this relevant? Does Rust support it?