I agree that a one-shot (with multi-trigger) PWM is not the everyday usage of a PWM, but I had a design where this was the only right solution.
When the PWM reaches terminal count (TC) I change programmatically the period by using the appropiate API, assuming that the PWM would be in the very same state as if It had stopped it with the API PWM_Stop() and now needs a hardware trigger to run once more.
To my surprise I discovered that when the PWM was triggered again the newly programmed period has not been accepted and the previously written period value was taken instead, so it looked like a one-cycle delay of the PWM's period. Experimental delays did not change the situation.
Of course I did create a MyCase and it took 14 days(!!) for Cypress's conclusion that the behaving of the PWM is quite o.k. since the datasheet tells that in a running PWM the next period is red at TC, while I still believe that the PWM is stopped and should accept the new value immediately.
When talking about fixed-function components I would accept that because changing would require a change in the silicon but since we are in PSoC world with UDB components a simple "repair" of the component would remove this obvious error, at least a clarification in the datasheet would save us some hours of trial-and-error testing.