I disagree with your unarticulated nugget! Or rather, I disagree with the implication of universality. In particular, it's easy to conflate +mold with $-, but this is simply wrong. A mold is first of all an identity* function, and it's potential properties of partiality or non-identity are subservient to this spirit. $- is never an identity function, asterisk or otherwise (unless it's clammed on the bunt of its product mold). +mold is in fact defined as _|~(* +<). The macro expansion for +* was just wrong.

It might be clearer and more accurate to define +mold (and the +* expansion) as $~(* $-(* *)).

And it's worth noting that the different arm types should be represented in +hoon (or maybe +synthetic-hoon), and expanded in +open:ap as is right and proper. Expanding (and effectively defining) them in a cooked parser gate is Not Good(tm).

I would say that we don't have the capability to not support manually-defined mold-builders, although they should be frowned upon. Ironically enough, they already don't have this problem due to the definition of +mold given above.

LGTM upon re-review

I still don't get why it's $~(* $-(* *)) instead of $~(|~(* +<) $-(* *))

It seems to me that * just is the default mold -- it's the identity function on nouns, specified axiomatically instead of by construction (at least as far as the syntax is concerned).

The macro expansion does seem a little too cute, but that's an implementation detail of +ax that can and should be rectified:

> ~(open ap (ream '*'))
[%brcl p=[%ktsg p=[%ktls p=[%bust p=%noun] q=[%ktls p=[%dttr p=[%rock p=%$ q=0] q=[p=[%rock p=%$ q=0] q=[%rock p=%$ q=1]]] q=[%rock p=%$ q=0]]]] q=[%$ p=6]]

Ah, okay, I see it. Relatedly, I found a nice hoon emoji:

> (*_*)
0