It seems one of the dependencies broke the tests. They work perfectly with my 20 days old package-lock.json but fail after a fresh install. Same happens to me on master.

Just to be clear:

import * as foo from 'foo.macro'

foo.baz('hi')

// would basically be the same as

import baz from 'foo.macro/baz'

baz('hi')

So as the macro author I would need a baz module if I want to support namespaces?

If that's the case then we definitely cannot do this... The only way I'll do anything about namespaces is if:

import * as foo from 'foo.macro'
foo.baz('hi')
// is the same as
import {baz} from 'foo.macro'
baz('hi')

No, as the macro author you just don't distinguish between import * as foo and import foo. No extra effort by macro authors is needed to support namespace imports.

It is as if

import * as foo from 'foo.macro'

foo.baz('hi')

// before running a macro would become
import * as foo from 'foo.macro'

foo.default.baz('hi')

The added tests contain a simplified version of a macro I already use. The original version proxies imports from Material UI so that I could use a wildcard import without compromising the tree shaking. Except that I can not fully replicate the semantics of import * as MUI from '@material-ui/core' with a macro yet because import * as MUI from 'my-mui-proxy.macro' crashes the plugin.

Lastly, if a macro author wishes to make

import * as foo from 'foo.macro'
foo.baz('hi')
// the same as
import {baz} from 'foo.macro'
baz('hi')

he can still do so himself. In fact most of the code to implement that is already present in my test macro. It just needs to be generalized and extracted as a helper.

Oh, I see. I really want this:

import * as foo from 'foo.macro'
foo.baz('hi')
// the same as
import {baz} from 'foo.macro'
baz('hi')

Without the author having to do anything fancy (like having to apply the baz behavior to both references.baz and references.default.baz).

It is far from trivial to make this transparent to a macro as I detailed out in the #111 thread.
The two cases differ from AST perspective.
foo.baz reference is an expression and baz reference alone is an identifier. Either a macro will now have to handle that difference in context (breaking change) or a plugin needs to preprocess the AST and inline foo.baz as baz possibly running into naming collisions (rabbit hole of complexity).

Also if we managed to solve the above mentioned issues what would happen here?

import * as foo from 'foo.macro'
const bar = foo
// or
console.log(foo)

It is a reference but not to a named import and now not a default either. How do we pass it to a macro?
We would again need something like SymbolNamespace for a macro to be able to access this reference within references object without a risk of naming collisions.

I could also argue that if we transparently handle cases of import * as foo we should do the same for import foo. Or otherwise it will confuse a considerable number of macro users.

Articles such as this show that the difference between import * as foo and import foo is not obvious.

the difference between import * as foo and import foo is not obvious.

The difference may not be obvious, but I'm committed to try to follow the spec as closely as possible and not drag CommonJS issues along with us into the future.