There's no way, in the current implementation, to represent the capturing abilities of the Coordinator or Pincher.
Pincher capture is a form of (conditional) burning. It is not a move, so I don't think it should be represented in the move notation. If the Interactive Diagram were to support it, it should be through the burnZone spec (and captureMatrix for indicating which piece burns).
Now there is of course a spatial aspect to a burn zone, and its extent can very well be defined in Betza terms. As the ID already does. In this definition it is implied that it specifies capture, or in fact rifle capture at all the indicated locations, as an automatic side effect (i.e. mandatory when possible, but not required to be possible). We could elaborate on this definition by allowing modifiers on the atoms. E.g. dK would specify burning of all adjacent friendly pieces. Then you could also specify multi-leg burning. Pincher capture is a form of bouncing grasshopper capture, [dD-bucW]. (This uses the d-u kludge for specifying friendly hopping over the D squares, to capture at the jumped-over W squares.) In a burnZone definition the capture would be understood to be rifle capture. (So perhaps the c should be omitted, as in burnZone specs it is implied that the destination indicates enemies there disappear.)
Coordinator capture (also a form of burning) would be harder to describe. It would be multi-hopping hook-mover hopping to the friendly King, followed by reversal of the second leg of the hook move to make the capture. Problems in expressing that in the current XBetza implementation is that there is no way to specify friendly King capture (so the capture-unload trick cannot be used for the friendly hopping): k captures the enemy royal, ck every enemy non-royal, but dk would logically mean every friend or the enemy royal, with is not redundant, so there is no justification for a special interpretation "every non-royal friend" in analogy with ck (which was otherwise redundant). And this would not be the interpretation we need (only the friendly royal) anyway. The second problem is that although multi-hopping can be indicated with the aid of parentheses, the 'iso' mechanism would not be able to exactly reverse a combination of hops. Not even if we specify that repeated use of i would refer to ever earlier previous slider legs rather than always the latest: a mechanism to force an equal number of hops in the reverse leg would also be needed. A simplification would be to allow pp as indication for "hops arbitrarily many". Then [ppcR-sppk'R] would do it, with the conventions that use of an explicit c in the definition of the burn zone indicates the victim of the one rifle capture it will do, and the apostrophy in k' means friendly King. (This use of apostrophe or double quote on mode modifiers could be used as a general mechanism for indicating friend-only or foe-only, so that it could also be used on p, and the d modifier would become redundant, and could be replaced by c'.)
Don't hold your breath until any of this gets implemented, though. It is already possible to do these captures with the aid of additional scripting, as can be seen in the Ultima Diagram. Considering how extremely uncommon these pieces are, that seems good enough.
Pincher capture is a form of (conditional) burning. It is not a move, so I don't think it should be represented in the move notation. If the Interactive Diagram were to support it, it should be through the burnZone spec (and captureMatrix for indicating which piece burns).
Now there is of course a spatial aspect to a burn zone, and its extent can very well be defined in Betza terms. As the ID already does. In this definition it is implied that it specifies capture, or in fact rifle capture at all the indicated locations, as an automatic side effect (i.e. mandatory when possible, but not required to be possible). We could elaborate on this definition by allowing modifiers on the atoms. E.g. dK would specify burning of all adjacent friendly pieces. Then you could also specify multi-leg burning. Pincher capture is a form of bouncing grasshopper capture, [dD-bucW]. (This uses the d-u kludge for specifying friendly hopping over the D squares, to capture at the jumped-over W squares.) In a burnZone definition the capture would be understood to be rifle capture. (So perhaps the c should be omitted, as in burnZone specs it is implied that the destination indicates enemies there disappear.)
Coordinator capture (also a form of burning) would be harder to describe. It would be multi-hopping hook-mover hopping to the friendly King, followed by reversal of the second leg of the hook move to make the capture. Problems in expressing that in the current XBetza implementation is that there is no way to specify friendly King capture (so the capture-unload trick cannot be used for the friendly hopping): k captures the enemy royal, ck every enemy non-royal, but dk would logically mean every friend or the enemy royal, with is not redundant, so there is no justification for a special interpretation "every non-royal friend" in analogy with ck (which was otherwise redundant). And this would not be the interpretation we need (only the friendly royal) anyway. The second problem is that although multi-hopping can be indicated with the aid of parentheses, the 'iso' mechanism would not be able to exactly reverse a combination of hops. Not even if we specify that repeated use of i would refer to ever earlier previous slider legs rather than always the latest: a mechanism to force an equal number of hops in the reverse leg would also be needed. A simplification would be to allow pp as indication for "hops arbitrarily many". Then [ppcR-sppk'R] would do it, with the conventions that use of an explicit c in the definition of the burn zone indicates the victim of the one rifle capture it will do, and the apostrophy in k' means friendly King. (This use of apostrophe or double quote on mode modifiers could be used as a general mechanism for indicating friend-only or foe-only, so that it could also be used on p, and the d modifier would become redundant, and could be replaced by c'.)
Don't hold your breath until any of this gets implemented, though. It is already possible to do these captures with the aid of additional scripting, as can be seen in the Ultima Diagram. Considering how extremely uncommon these pieces are, that seems good enough.