This makes me wonder if the on_fragment filed is redundant, when the name of the operation file should have been be the same. Are there any cases in C8y where the operation name and this fragment name could be different?

I wouldn't assume that the fragment and the name of the operation are the same. These are custom operations which means that the customer is free to configure them however they want, so being more explicit would be safer here with the downside of a bit of boilerplate.

Okay. It would have been better if we could drop that additional level of indirection with the name and then the fragment name. Because that design enables users to define multiple operation files with the same on_fragment value in them. But, when the actual c8y operation is triggered, only one of them can be used, as we can't trigger multiple tedge commands in response to a single c8y operation.

But, if it is still desired, we need to add some additional validations to prevent conflicting operation files with different names, but with the same on_fragment value. Current behaviour is that it picks the first operation file in the alphabetic order. It'd be better to add some additional logs to highlight to the user as to what is picked and the others are ignored.

@Ruadhri17 if you're also wondering why any user would want to declare one name in the supported operations list (the operation file name) and use an entirely different name for his operation fragment, here is the use-case: The declared supported operation name is typically used to enable/disable UI components in C8y. The developer of that UI component dictates the expected operation name. And it is a possibility that the custom operation developer may not be able to (or don't want to) reuse the same name for his operation as well. In such cases, this design would help.