these fields should be called actionIndex and actionName, right (see specification above)?

Correct, there is a mistake in the example. The fields should not reflect a state of the event. The event state is indicated by the event type (.triggered/.started/.status.changed./.finished).

Thank you! I corrected the spec.

According to Issue #1849, it should also possible to include arbitrary strings within the result (e.g. "remediation file not configured"). Should we add an additional field (e.g. message) here, or should we remove the enum restriction?

I would propose to introduce an additional message field. Otherwise, the event receiver would need to correctly interpret the result message. This can lead to misinterpretation.
The same is true for the status field.

Should we add: statusMessage, resultMessage (which are optional)?

@agrimmer What is your opinion on that?

I would prefer introducing a new field "message". This would allow us to use the "result" field for the evaluation result.

My proposal of having a dedicated statusMessage and resultMessage is over-engineered since there cannot be a result when the status is errored or unknown. As a result, just one message field is sufficient.