Forked from #40 (comment).

We have three kinds of specifiers that people have asked for (implied: that we may or may not want to support):

1. Getting the public interface of the package. This will allow people using exports to actually unit test their packages (since exports do not apply to relative specifiers). Examples: ✩ (the main/default export), ✩/subpath
2. Adding custom aliases that are only valid inside of the package boundary. Examples: ✩data/emoji.json, ✩fetch.
3. Accessing arbitrary paths relative to the package boundary. Examples: ✩/src/model.mjs.

Of these, only (1) and (3) actually conflict. (2) could share a symbol with either one of them. A concern raised by @guybedford was that if (1) and (2) share a symbol, it may be confusing.

So to me the options are:

1. One sigil, no (3):
   • Use ~ and ~/ to mean "this package as if it was imported by name".
   • Allow ~<name> to be used for custom aliases within the package.
2. Two sigils, optional support for (3):
   • Use ~ and ~/` to mean "this package as if it was imported by name".
   • Use #<name> for "private names", aliases only visible inside of the package.
   • (optional) Use #/ for "paths relative to the package boundary".

For packages that don't use exports, ~/ and #/ are effectively the same but that would change once they choose to remap subpaths and/or lock themselves down.

My preference right now would be ~ + # without support for importing non-public paths relative to the project root. There would still be design space for adding #/ in the future if it becomes truly necessary. Both ~ and # can be used as specifier prefixes since ESM only recognizes ./, ../, and / as valid relative URLs.