Related feature: sub-palettes and palette swaps, for effects such as palette swaps on the NES, where each sprite and tile used a 4-colour subset of the NES’s total palette. Being able to define sub-palettes (with specific order! two sub-palettes with the same colours in different orderings should be considered separate) and at least preview the effect of applying them in Aseprite would be pretty neat. Being able to assign different sub-palettes to frames would allow for great retro effects, as well as allow the palette cycling effects shown by the OP.
I’d imagine this would require a huge overhaul to how colour and animation are handled in Aseprite though (since now frames would need to be able to use just one image, and only change the sub-palette, and this all would need to work with existing features), and I wonder if perhaps this sort of work would be better-suited to a script that just makes an exportable preview of the effect, so that the source file could remain a single frame. As a script (or a series of them) that does one specific thing rather than generalise sub-palette workflows, it’s be much easier to implement.
Edit: While in the shower, I came up with two UI ideas for the general case, and this feature seems much less daunting now :D
Both allow specifying a palette for a given frame of animation. In both cases, the palette works as a palette-swap, meaning that it works based on the index of a colour in the palettes, so that the Nth colour in the new palette always replaces the Nth colour in the source palette. If the source palette has more colours than the new palette, colours in those extra indices are not replaced.
A. Palette Animation “Layer”, an approach more like DPaint
A special “layer” can be enabled in the “Show” menu. When enabled and visible, the palette swap effect is applied, and when disabled or hidden, the effect is not. Each cel of this layer, rather than containing image data, contains a palette. When a cel on this layer is clicked, a palette editor appears, which functions just like the regular side bar one, allowing changing colours, moving them around, adding, removing them, or even loading a different palette from file. Each cel can have its own palette, but they can be linked to share a palette. The default state for a cel is the palette associated with this file, and only changed states need be stored in the .ase file. Cels on this layer cannot be deleted.
To create a palette cycling effect with this, the palettes for each frame would just need to be arranged to cycle, which should be easy with the palette editor’s drag-and-dropping feature.
B. Palette Adjustment Layers, an approach more like Photoshop
Implement a new type of layer, an adjustment layer that allows palette swapping in the way described above (perhaps we could have other adjustment layers eventually xP). The layer properties contain the palette it changes to, and it affects everything below it. The layer’s pixel content is a mask (perhaps just pure black and white, or perhaps full greyscale to allow gradations of opacity). This means the layer’s adjustment can be applied just to parts of an image. The layer itself is just a regular layer, meaning its content (the mask) can be animated, but its properties (including the palette) are the same across each layer. This could allow for some very cool transitions between e.g. two palette-swapped versions of a scene.
To create palette cycling with this would require multiple palette adjustment layers, one for each step in the cycle.
A is more convenient for palette cycling and basic palette swaps, but B is more powerful and shares a basic approach with an already established convention in modern graphics editors (adjustment layers), which could possibly be expanded in Aseprite layer for other types of adjustment layers. Creating cycle effects in particular could be sped up/automated with scripts in both cases.