I see the second form I provided above replacing macro_rules, and that is not surprising as its grammar is pretty similar to that of macro_rules (except for an annoying difference in how macro expansion body blocks are ended: with a semicolon vs a comma, that also behave differently in what usage they find correct).
In this thread I’m more concerned with the first syntactic form. Is that meant to become sugar for the just-stabilized proc-macro’s?
BTW, for an additional, real world macro problem I’ve run into is that macro’s can’t nicely define other macros that have some of their definition handed down to them by virtue of being defined by the first macro rather than simple argument passing (I’ll call these closure-like macros, as they’re analogous to closures in the general sense). That’s to say, they can define them, but not without leaking weird impl details to the top level macro, at the very least the $ sign in something like
\$(...) * for matching multiplicities with kleene operators.
While not a hygiene issue in the traditional symbol clash sense, I’d definitely call this a hygiene issue.