So in the meantime I got the answers to my questions.

When CH1 triggers, the TIM3->SR register gets the value of 0x0000001f. I have looked at it in the debugger. The other channels are not even set up, so their interrupts should be disabled, right?

Well as it turns out, the channels, which are "not set up" are rather in their reset states. So the reset register settings apply to them.

It enters the TIM3_IRQHandler function and it executes the ISR of all the channels. Not only that, but it doesn't even reset the CCxIF bits when I tell it to. It just goes over the line and does nothing. According to the debugger, the TIM3->SR value remains unchanged.

Yes, it executes them, because the interrupt flags are set, no matter the settings in the TIMx->DIER register. The TIMx->DIER register serves only to set whether an interrupt is made, not if the interrupt flag sets or not. So what happened is, the CCRx registers of the unused channels were 0, and when the CNT register reached 0, they set the corresponding CCxIF interrupt flags. So in the interrupt handler I have to check not only if the interrupt flag is set for the channel, but if the channel DIER bit is enabled.

The reason all flags appeared to set at once is because in debugging mode the timer clock continued to tick, even when the code execution halted. That explains everything else that was unclear.

You don't need the complexity of chained timers to achieve this on STM32. You can either use TIM_RCR for certain timers to have a Nth UEV interrupt change polarity, or you can simply implement a software counter in an UEV interrupt handler to emulate RCR.

But the most important thing is to use preloaded OC register control for correct glitch-free operation. There are two modes of preloaded control that you can use (TIM1 as an example):

1. Output in PWM mode with preloaded OC control:

TIM1_CCMR1 = TIM_CCMR1_OC1PE | TIM_CCMR1_OC1M_PWM1;

In this mode, TIM_CCR1 is preloaded, i.e. any changes to it will be applied after UEV (update event). In other words, every write operation changes the next duty cycle, not the current.

This mode is mandatory for glitch-free PWM mode operation.

2. Preloaded commutation control:

TIM1_CR2 = TIM_CR2_CCPC;

In this mode, changes to certain bits in the TIM1_CCMRx and TIM1_CCER registers are preloaded. The values programmed are applied upon COM (commutation event) which can arrive either as a trigger or via TIM1_EGR = TIM1_EGR_COMG.

This mode is required for glitch-free commutation control.

In your code, you change polarity via TIM2_CCER without any preloaded control enabled, hence glitches are unavoidable. It's also worth noting that your code has excessive latency due to weird statements like while(TIM2->CNT);. In correctly written code, changing polarity even without preloaded control will still give good results albeit not ideal.

The initial requirement is: The original firmware generates PWM (duty cycle 50%) and every 8 cycles inverts the signal

It's hard to come with a good solution without further details. It's unknown, for example, whether duty cycle is always fixed at 50% or should change. If it's fixed, we can come up for instance with another approach - use timer PWM mode with preloaded OC control at twice the frequency and have duty cycle alternate between 0% and 100% in a preloaded fashion. At the 8th iteration, alternation changes.

A very simplified interrupt-based example:

void tim1_up_isr(void) {
    static int n;
    if (!(++n & 7)) return; // Change polarity every 8th iteration, i.e. do not alternate
    TIM1_CCR1 ~= TIM1_CCR1; // Alternate duty cycle between 0% and 100%
}

...
TIM1_BDTR = TIM_BDTR_MOE; // Enable main output
TIM1_CCMR1 = TIM_CCMR1_OC1PE | TIM_CCMR1_OC1M_PWM1; // PWM1 mode, buffered CCR1
TIM1_CCER = TIM_CCER_CC1E; // Enable output
TIM1_DIER = TIM_DIER_UIE; // Enable UEV interrupt

The above is just an example of the preloaded PWM control concept and in no way is the most efficient code.

In the ultimate case, when duty cycle can change and on-the-fly polarity/mode change is required, the only correct way is to use both preloaded commutation control and PWM mode with preloaded OC control.

As @pmacfarlane already said in comments, (TIMx_ARR + 1) determines PWM period, TIMx_CCRx deterimines pulse lenght (thus together they determine duty ratio), and both are multiplied by (TIMx_PSC + 1) which thus determines granularity i.e. the timing step in which both period and pulse length can be adjusted. Generally, you want to keep TIMx_PSC as low as possible, but that is limited by the fact that most STM32 timers are 16-bit (exceptions are generally TIM2 and TIM5). For example, with your 100MHz timer clock, the maximum period in a 16-bit timer is 655.35us; if you want longer period, you need to increase PSC accordingly.

There is only one counting element in each timer, so period of all four channels of one timer is always the same, only their pulse length can be individually set. In other words, you cannot generate PWM with different frequencies from different channels of one timer.

Also, in 'F4 timer, you also cannot generate PWM on different channels with random phase shift, one of the pulses edges is always aligned together on all channels, as it's generated by the Update event (overflow); or in up-down mode the middle of all pulses is aligned together (newer STM32 models do have modes where this limitation can be circumvented).

Do you check for the right interrupt flag in the interrupt handler? Also keep in mind that you have to clear the flag right away.

My IRQHandler looks like this, if this is any help for you.

void TIM3_IRQHandler(void) {

    if(LL_TIM_IsActiveFlag_CC1(TIM3) == 1) {
        LL_TIM_ClearFlag_CC1(TIM3);
        TimerCaptureCompare_Callback();
    }
}

Edit:

OK as it seems, the HAL_TIM_OC_DelayElapsedCallback interrupt is only fired when the timer overflows (i. e., resets). This means that you have to enable the overflow interrupt, as the HAL_TIM_OC_Start_IT only enables the capture/compare interrupt. You only need to enable it before enabling the timer.

__HAL_TIM_ENABLE_IT(&tim3, TIM_IT_UPDATE );