i’m still a relative newcomer to zig, so i’m not necessarily aware of some of “deep” implementation issues as well as all of the design alternatives…
having had a favorable experience with namespaces back in C++, i immediately knew the situations where this feature would be helpful…
based on the description in the docs (plus examples at this forum), it initially struck me as a very convenient way to merge disjunct source files with lots of top-level declarations… the alternative would have me explicitly creating a top-level file whose declarations are basically “renames” of internally imported declarations…
but as i progressed further in my design of Zig•EM i relied on usingnamespace in a rather novel manner… to illustrate, here’s an example from a recent article of mine…
long story short, but each .em.zig source file is compiled TWICE in the Zig•EM framework: first with the file’s top-level declarations merged with the EM__META namespace; and then with the file’s top-level declarations merged with the EM__TARG namespace…
[[ read on in this article to understand the motivation ]]
lacking usingnamespace, i could very easily generate TWO derivative source-files that respectively merge in the EM__META and EM__TARG declarations… i’m not sure whether there is an alternative solution using other language constructs…
i’m not sure that the Mixin alternative described by @AndrewCodeDev would apply here… a recent topic talking about “source code rewrite transformations” had @mnemnion suggesting a solution with usingnamespace 
in summary, it’s essential in my current framework design… but if i start doing some upstream source-code transformation anyway (for situations for which there is my only alternative), then i can easily subsume my current use-cases for usingnamespace…