Apparently no way to import named object constants

[gwhitney]

Describe the bug
Suppose I am doing a lot of computations with Eisenstein integers and I would like the symbol w to denote (-1 +√-3)/2, the complex unit of the Eisenstein lattice (all other Eisenstein integers can be written as m + n*w where m and n are integers). I would like to import a definition of w as this complex number, but such an import does not seem to work (similarly, it doesn't seem to work to import a Fraction or any other mathjs value that is represented as a JavaScript object).

To Reproduce

const math = create(all)
math.import({w: math.complex(-0.5, Math.sqrt(3)/2)})

throws error Error: Cannot import "re": already exists rather than enhancing math with a property math.w equal to the Eisenstein unit.

Discussion
The difficulty appears to be that math.import recurses down objects arbitrarily deeply looking for values, functions, or Factorys to import. Is there a use case for even doubly-nested values in the items to import? If not, I would suggest that the immediate object properties of an imported object be taken "as-is" as the item to import, rather than flattening recursively. If there is, then we need a flag or some other way to distinguish objects that are meant to be imported as named entities.

For example, we could compute the mathjs typeOf each entity as we go down, and if it is ever a type known to mathjs other than object or any or unknown, stop the recursion there and take the definition. This approach would be my recommendation: extremely unlikely to break any existing nested imports that may be out there "in the wild," while allowing you to import constants of any known or added mathjs type.

Current workaround
math.import({w: factory('w', [], () => math.complex(-0.5, Math.sqrt(3)/2))}) does work to create a new mathjs entity math.w as desired, since the recursive flattening is stopped by Factory objects. But this method is a bit verbose/redundant/heavyweight for such a simple import.