This is both an improvement and feedback post to this WIP by InputEvelution. The improvements are located in 1-A (1 frame), 1-D (2 frames), 1-F (2 frames), 1-G (3 frames), 1-I (3 frames). 1-J (2 frames), 1-K (1 frame) and 1-L (1 frame), totalizing 15 frames.
(Of note that while this movie file is only shorter by 12 frames, it does lead to the post-(1-L) menu inputs 15 frames faster.)
In isolation the routing of each level looks very solid. I only managed to save one frame in a couple levels by balancing the total load between both players a bit better. To me this shows that the author has a good understanding of what an optimal two-path solution should look like, and how to obtain it empirically. However, there is something more important to note, and this was where most of the found time save came from.
Hammer animations are cyclic! And both must be completed before the level can end.
More precisely, Player 1's hammer animation is on an 8 frame cycle while Player 2's hammer animation is on a 7 frame cycle. After a hammer completes its last animation cycle, it visually disappears after exactly 14 frames. Then the end of each level unfolds with unchanged timing. So the timing of a level is conditioned by the completion time of the last cycle of each hammer animation. This behavior can be compared to the "frame rules" of Super Mario Bros., except there are two concurrent "frame rules" here, and you have control over when each individual "frame rule" cycle starts.
What this means is that there will always be a "limiting" hammer between the two, while the other one might have some margin: either some room in its last animation cycle or even enough time for an extra cycle. Knowing this, it is possible to track the advancement of the hammer animation cycles, identify the limiting hammer and, if possible, balance the load between both players so that the limiting hammer completes its last animation cycle as early as possible (sometimes enough to change the identity of the limiting hammer).
Basically:
Because of these hammer animation cycles, this looks like a pretty difficult optimization problem. Significantly more so than your traditional shortest path problem.
While this game as a TAS does not directly translate to a common computer science problem, it could be interpreted as a two-path covering problem on a planar graph, coupled with a batch scheduling problem on two machines with unit-time tasks. So brute-force seems inevitable.
While this game looks bottable, in my opinion it is possible to get a very clean result by hand. A good optimization strategy could be to ignore the hammer animations at first and find a solid solution with as few idle frames as possible (as it has been done by the author), and only then slightly tweak the level route to optimize the completion of cycles for both hammers.
Now that the hammer animation shenanigans are understood better, and given the quality of the first optimization phase achieved by the author, I can only be optimistic about the future of this project.
Finally, as a side note, it might be possible to use the dusting move in order to change the timing of the hammer animation cycles and save a few more frames. Though this is only a short in the dark.