It’s a tough decision to make, I can see arguments both ways but I have definitely been caught out by a conflict. IIRC multiple entry type defs with the same name, in different zomes, but in the same DNA… it caused core to either hang or crash.
I don’t believe this should be allowed (and the namespacing is a good preventative measure from this perspective). In our case it ended up being a code smell- within the “planning” DNA, Intent
and Commitment
zomes both had bindings to Process
in “observation”. Really what should be happening is that Process
remote entry stubs are defined in their own separate zome within “planning”, rather than being defined in either of the other two places (which currently, they are). So, an error that explicitly prevents this gets my 
On the other side of the discussion you have utility libraries that consumers of mixin zomes need to consume (see holochain_anchors and the anchors zome). If namespacing is to include crate_name
, then some of these utility libraries may have to have curried APIs or be made otherwise configurable with the name of the mixin zome crate they target. Perhaps this small amount of additional complexity is acceptable… you could always generate the library crate code via a macro.
In many cases this limitation will be OK- polymorphism in mixin zome logic is mostly achieved via the helper library layer, not the mixin zome layer. But there might be cases where one helper library wants to be able to plug different storage backends with slightly varied data layouts. I’m not sure what sorts of requirements might drive that or whether it would even be needed; but it does need to be called out that this degree of namespacing prevents such functionality. As per above, I’m OK with this.
Should crates be able to commit entries internally?
I think they have to be able to. You mean zome crates? I spent some time early on trying to create an architecture where the business logic was separate from the hdk
entries & links APIs, but it was a completely non-intuitive way to have to think and I wasn’t sure inverting the logic really made sense or was even possible. The whole thing with a Holochain app is basically implementing business logic on top of storage primitives, after all.
How can I specify an entry from another zome if we enforce namespacing? Do we need another entry type like External
?
Some native support for this would be very cool, because managing remote base entries yourself involves a lot of moving pieces. But I have noted that there is a lot of additional complexity involved with external links, and network versioning issues to consider.