SKILL namespaces vs SKILL++ environments

I've been playing around with namespaces and environments recently, and have observed the following
pros and cons:

• SKILL++ Environments
  • Pros:
    • Easy to use.
    • Well-documented in the SKILL++ manual and the Scheme literature.
    • No need to enumerate the names to be hidden (as with addToNamespace).
    • Low-impact on the global environment.
    • Can use toplevel('ils theEnvironment(myFunc)) to set the toplevel evaluation context inside an environment.
    • Implementation is mature.
    • Can programmatically get a list of all symbols in an environment.
  • Cons:
    • Can't put a macro in an environment.
    • No builtins for importing, exporting, and shadowing.
    • Can't put a class or a generic function in an environment.
• SKILL Namespaces
  • Pros:
    • Works for all kinds of names, including macros.  (But not classes and generic functions, which are always global.)
    • Comes with builtins for importing, exporting, and shadowing.
  • Cons:
    • Confusing to use, because it works by altering how the reader maps textual names to symbol objects.
    • Does not currently interact smoothly with infix operator conversion.
      • E.g. Define your own "plus" in a namespace, shadowImport it, and read("1 + 1").  You will get the builtin plus primop rather than your redefined plus.  But if you read("(plus 1 1)"), you will get the redefined plus!
    • Heavy impact on global environment due to useNamespace().  Need to use unwindProtect() to ensure namespaces are unused if there is a load() error, lest other SKILL developers on the other side of the world (who don't even know about namespaces) become very confused.
    • Need to enumerate every single name that goes in the namespace.  If you forget one, that name will be in the global namespace!  No Lint check for this either, unlike the ERRGLOBAL for let()/prog().
    • Can't change the "current namespace": there is no equivalent to Common Lisp's in-package().  The global namespace is always the current one, which makes SKLL namespaces significantly less pleasurable to use than CL packages.
    • Implementation is immature: it's easy to make Virtuoso core dump when playing around with namespace functions.
    • Can't programmatically get a list of all symbols in a namespace.
• Name Prefixing
  • Pros:
    • Time-tested, traditional "solution" to the namespacing problem.
    • Easy to understand.
    • Well documented in the SKILL manual and the Emacs Lisp info docs (Emacs Lisp uses a similar convention.)
    • No risk of crashing Virtuoso.
    • Works for all kinds of names, including macros.
  • Cons:
    • Doesn't really solve the name collision problem: names can still collide if two programmers happen to choose the same prefix.
    • Names become longer and harder to read than with namespaces or environments.
    • Need to take care to enumerate local names in a let() or prog(), though Lint is available to check if you forgot any.
    • No builtins for importing, exporting, and shadowing, though you can roll your own.