From a user prospective Scalqa does not have packages. There is just one single root package 'scalqa' (always fully imported as
import scalqa.*), which contains 5 root member objects:
Langholds language extensions
Valholds generic containers framework
Genholds general utilities
Jholds Java utilities
Fxholds GUI API
These root objects also contain members of their own. Those members can have their members and so it goes as deep as required.
The trick is that parent name is an essential part of member name and this member can be meaningfully called from the root without any imports. For example:
Lang.Int.G.Bufferis a generic buffer specialized for Int primitives
Val.Collection.Mutableis a mutable collection interface
One of the most precious resources in today's programming is name space. Every imaginable piece of functionality, we might need, already exists somewhere. The challenge is to make accessing it cheaper, then the potential benefits. Often times 'import' statements are not justified to bring in trivial functionality.
In Scalqa code there are practically no imports (except for rare conflict resolutions). All the functionality is available from the root, but few levels of hierarchy provide unlimited naming opportunities for even the most trivial resources.
Of course there are packages on implementation level, but they are not a part of public API and should not be called directly. All public functionality is exposed as objects, which can be imported (when required) the same way packages are.
Probably "no". It is better to write programs the regular way. It would take months of considerable effort before first benefits are realized. And even then, H2O is mostly beneficial for large, very interconnected library type code.