Note: Imported names/paths are made up, and are intentionally made more complicated for the sake of showing off features. For example, std@io.file is likely to just sit in either std@io or std@file directly.

The syntax for imports is not finalized, but most of the semantics are. The most likely option is heavily inspired by D.

// TODO: Not happy with this syntax. I like `std:io.file` visually the most, but that's ambiguious. Perhaps `std::io.file` (despite my dislike for double colon), `std\io.file`, or such?
import std@io.file;
// another alternative (but it eliminates the concept of explicit packages)

The other option to above would be to have string-based imports:

import "std:io/file.coy";

… which have some benefits (more clarity of path resolution, for one), but also downsides (no std@io.file.File or such access).

In the first 2 cases, the imported symbols are available either directly, or via a fully-qualified name:

var file = new std@io.file.File("some_file.txt");
// either equivalent or an ambiguity error (depending on how many imported modules define the symbol)
var file = new File("some_file.txt");

Only the latter is supported in the case of import "std:io.file". But see below for renaming options.

There also exist partial and renamed imports:

static import std@io.file;	// available *only* as std@io.file.File
import std@io.file: File;	// available *only* as File
import f=std@io.file;		// available *only* as f.File
import f=std@io.file: File;	// ERROR; illegal (TODO: could make it available as f.File *and* File?)

All imports are private by default, but the symbols may be made available transitively to other files that import the current one:

// TODO: Is this feature worth the added (admittedly minor) complexity?
private import std@io.file;	// the default; generally bad style, but provided for completeness
public import std@io.file;	// available to all importers
package import std@io.file;	// available to importers in the same package

Note that a “bad style” option is allowed. It is the philosophy of the language that programmer ultimately knows best when it comes to code style. For example, an explicit private import in a sea of public ones may be beneficial.