To do what you are describing, I think they would have to have a time-line based function. You would assign each RGB software controller the number of LEDs (which is how it works now), but add a start time and a rate or duration. For example, if you wanted the LEDs to sequence across multiple LED strips you would do the following.

Assuming RGBpx port 1 has a 15-LED strip connected and RGBpx port 2 has a 30-LED strip connected, and you want one lit LED to move sequentially from LED strip 1 LED #1 to LED strip 2 LED #30 -

Add an RGB controller to RGBpx port 1 and select the Sequence effect. Set it for 15 LEDs, NEW PART - Set Start time T=0, Rate=3 sec. This would tell AQS to start this effect at T=0 and complete one cycle in 3 seconds across 15 LEDs.

Copy the RGB controller to RGBpx port 2 and stretch it out to 30 LEDs. NEW PART - Set Start time T=3-sec, Rate=6-sec. This would tell AQS to start this effect at T=3-sec and complete one cycle in 6 seconds across 30-LEDs.

The chain trigger could be tied to a data value, OS event, Hot Key, etc.

I don't see how this could be supported without adding the concept of a time-line, which would require a significant amount of new code, and updated GUIs in the application. Many of the preset patterns may not make sense to sequentially trigger like this, but some of them have definite potential. I ran into a similar issue that may also be solved by doing this. I have 2 Farbwerk360s. They are both connected to AQS via USB but there is no way to synchronize them. I had LED strips on both Farkwerks that were set to identical effects. I quickly noticed that the LEDs on Farbwerk #2 are not in sync with the LEDs on Farbwerk #1. I got around this by rearranging some ports but a time-line that both Farbwerks could "see" would allow them to synchronize. It would be a "soft sync" in that multiple RGBpx ports in multiple Farbwerks (or Octo or whatever) could see the time-line and trigger at the proper time, but they could still drift during effect playback. In the pro AV world we call this "A starting gun and a prayer". You can get away with it when the sequences are short, which in this case they are. I suspect this would also only work while AQS is running as the time-line and start triggers would exist in the software.

There may be another way to implement this. I don't know if this something that AC would invest time in. They did a really good job with the whole RGBpx platform, but I don't think they have really done anything to enhance or improve it since it was released. I have only been using AC products for about 6 months so I may be wrong about this. Anyway, adding a time-line to the RGBpx software would open up a lot of possibilities. I don't know if iCue supports something like this, and I don't know how big of a selling point it would be. Seems like most AC customers are hard core custom loop guys who care a lot more about water cooling than RGB. The serious RGB enthusiasts will program an Arduino and build their lighting effects from scratch one LED at a time. Time-line based effects would be a powerful addition to RGBpx and I hope the AC guys read this thread. Maybe they will go for it, or come up with a better way to allow what you are after, and allow synchronization between multiple RGBpx ports spread across various AC devices.

You're right - this is a simpler approach. I don't know how difficult it would be to add something like this. I also don't think it would solve my issue of not having a way to synchronize 2 Farbwerk360s (or a Farbwerk360 and some other AC device that has an RGBpx port on it). It would still be a quite powerful addition and I hope that the mods will read this thread and consider it. They have a solid RGB control platform and the hardware is already figured out. I think any enhancements or new features that they may add will be additions in the AQS software - more presets, new preset controls, and your linking feature.

The only hardware change I would like to see is an increase in the 90-LED limit on the Farbwerk360 ports. 90 sounds like a lot until you start adding things like Corsair QL series fans which have 34 LEDs each. If they could get the limit up to 136 LEDs, a Splitty4 could handle 4 QL series fans. If the 90-LED limit is due to current limitations, they probably can't do this without a hardware change or some other software imposed limitation. Example - Assuming they can address 136 LEDs and its a current limitation, maybe they could set it up so if you put more than 90 LEDs om a RGBpx port, they limit the brightness to 70% and/or maybe not allow full white. I would be fine with either of these limitations to keep the maximum possible current draw below whatever the hard limit is in the hardware while increasing the limit to more than 90 LEDs. The current limitation is probably only a problem in the worst case - all LEDs lit at the same time, white, 100% brightness. Most people are not going to do that, but if they tried to, the software would not allow it. Here's hoping!

only an issue for QL users
for the current limit, the outputs shutdown if current draw is too high, requiring a reboot. AS displays a warning saying the channel has been shutdown because of a current surge (i discovered that testing full white on my fans).

I suppose the 90 LED limit is refresh rate limited.maybe increasing the number of LED per channel would require a different microcontroller to update such long strings with decent fluidity.
So many things to considerate i wouldn't bet on current draw alone at being the limit for the 90 leds
Coming from the corsair ecosystem, i much prefer more channels of fewer LEDs than the opposite. More often we're out of channels than LED count.