@olivier-renaud, that's a fair point about identifier confusion.  These are totally outside the normal code namespace, and I like the idea of changing up the syntax to make it look special.  (That was never an option in CPP macros.)  The chosen syntax won't matter much to the actual implementation - just tweaking the macro patterns.  Now we get to bikeshed on what might look better. :)

I don't really care for `name@provider`, just because that's inverted from the order that the existing tools refer to these fields.  Flipping to `provider@name` could be better, except '@' has the wrong hierarchy implication when read like "at", and there's also the past association with '@' pointers.  Maybe some other symbol wouldn't have as much baggage, like `provider$name`.  (I don't think any QWERTY-keyboard symbols are left without any rust meaning at all...)

SystemTap is relatively verbose with `process.provider("provider").mark("name")`, so that's not helpful for macro inspiration.  GDB refers to probes by `provider:name`.  DTrace uses `provider:module:function:name` (module being the binary, or crate in rust terms), and you can omit fields to leave just `provider:::name`.  So both GDB and DTrace resemble rust paths - maybe we should embrace that and go with `provider::name`?  Or maybe that's confusing if it looks like a real path but isn't, so just settle on `provider:name`?

If the colon is the initial separator, I think think it's fine to stick with commas for the optional arguments, `probe!(foo:bar)` and `probe!(foo:baz, arg1, arg2,...)`.  But since placing a probe is vaguely like a function call,maybe we could also use parentheses like `probe!(foo:bar())` and `probe!(foo:baz(arg1, arg2, ...))`.

Opening up syntax leaves endless possibilities.  Opinions and suggestions are welcome...