I will try 8-)

The main issue is protocol timing of the PWM. Below are some examples to clarify this.

The second issue is complexity of encoding and the time it takes to do so. This is more of issue with larger pixel counts.

• 4 step (4 bits) easily divides into a nibble and thus also in 8bit/16bit/32bit, so some tricks to encode multiple bits in one operation can be done. But it does require 4 bits to represent one bit in the protocol.
• 3 step (3 bits) doesn't divide into 8bit/16bit/32bits. So extra operations are needed to span 8bit aligned elements. (note that this complexity or flexibility also proves that DMX512 could be encoded using this hardware method with minor tweaks). Since this only uses 3 bits to represent one bit in the protocol, it uses 25% less memory in the DMA buffer.

example of timing issue:

The normal period timing for a bit in is 1.25us or 1250ns.
The Pattern defines when the pin is high versus low within this period; and how many steps in the pattern is Cadence.

Old 4 Step Cadence: this period is divided by four to define the available time slices for a pattern, so 312.5ns each

New 3 Step Cadence: the period is divided by three to define the available time slices for a pattern, so 416.666 ns each

Compared to RMT (or spec) for WS2812x: ¹

Compared to RMT (or spec) for WS2811: ²

Interesting. Thank you.
Are these inexact "cadences" possible cause for flicker? I.e. with 4 step WS2812 may be prone to flicker more than WS2811 but with 3 step it will be less prone to but WS2811 may be more prone to flicker.

As (normally) users do not change LED types "on the fly" why not choose best cadence on LED type? I know you support wide range of MCUs but some (constrained ones) are getting old and more and more people are using newer ones with enough RAM so choosing the optimum cadence may be worth the sacrifices of RAM. Just thinking out loud.

I can support it, and not difficult. But just another set in the matrix of methods. The new ESP32S3 LCD parallel is the only one that doesn't have a 4 step cadence at all, as the pull only had 3 step. I would have to implement it.

The problem is the cadence also effects the speed of the peripheral. The 3 Step has to run slower to take the same time as 4 steps. So, you can't mix 4 & 3 on the same peripheral, like any of the parallel methods. Except RMT of course as that uses the specific RMT encoding.

You can add an issue to track supporting both without compilation flag.