minmay: sure!
In a level's dictionary, tiles are referred to through shorts. Using 1.23 numbers for reference, values 0-1023 for those shorts refer to unflipped tiles, and 1024-2047 to flipped tiles. Within each of those ranges, up to 1020 of those tiles are actual 32x32 images from the tileset, whereas the rest are potentially animated tiles, starting from 1023 (and 2047) and working back down. So a level with a 10 tile tileset and two animated tiles would, assuming everything appears flipped, have values 0,1,2,3,4,5,6,7,8,9; 1022,1023; 1024,1025,1026,1027,1028,1029,1030,1031, 1032, 1033; 2046, 2047. What's important is that a single value, with no parameters elsewhere, tells JCS/JJ2 whether to load a flipped or unflipped and animated or unanimated tile for display and other interaction.

Now, animated tiles are themselves stored in the .j2l as a series of frames, and each of those frames is described by a short. As it turns out, that short uses the same function as does the rest of the game for figuring out which tile, flipped tile, animated tile, or flipped animated tile to display as a frame. Consequently, hex-editing values higher than the tile count into the frame of an animation can give crazy results.

Once you get to the actual display of this ingame, just speaking theoretically, there are at least two possible ways JJ2 could handle animated tiles. Minimally, the frame displayed at any given time for an animated tile, ignoring the cases of destruct scenery and other such events freezing animations regardless of speed, depends on how much time has elapsed since the beginning of the level (call it the gametick), the speed of the animation, and the sequence of frames within it.

So, one way JJ2 could handle this would be every gametick to see which animations should advance a frame and update all dictionary words containing that animation accordingly. The words, as stored in memory, would not actually contain animated tiles; instead, a separate list of where animated tiles appear in words would know which tiles to update and how often. However, this is not what JJ2 appears to do, perhaps because it would interact poorly with destruct scenery, perhaps for optimization reasons, perhaps arbitrarily.

Instead, based on this, it looks like every time JJ2 draws a tile to the screen, it uses a figure-out-which-tile-this-really-is function on the short value originally stored in the .j2l. If it's a simple tile, it just grabs that 32x32 image. If it's an animation, it asks the animation what its current frame is, and then uses the same figuring out function on the number the animation gives it, which can in turn refer to another animation, causing JJ2 to ask again what the current frame to display should be. I haven't tried, but I see no reason why you could not continue down this line, embedding animations into other embedded animations, until you hit the limit, although I assume any recursion would crash the game.

Functionally: suppose you have an animation A of a dancing flower. You also have a two-tile animation B, with speed 1, whose first frame is a blank tile and whose second frame is animation A. Whenever animation B is displaying its first frame, it will appear blank. But when it's displaying its second frame, the player will see whichever frame of animation A is the current one as determined by combining A's own speed and frame sequence with the gametick.

Dermo: I think it's the tileset in this upload.

ETA: Here, have a visual example. Given two normal animations, and one animation half the speed of the other two which switches back and forth between them, you should get a sequence like on the bottom. Of course, if the first two animations had different speeds and/or lengths, then that would make for a less regular pattern; alternatively, you might want to do something like put a trigger scenery event on the two-frame animation, to switch the level back and forth between all dancing mushrooms and all dancing flowers.