@alexshoe This is looking really good. 🎉

I left some minor comments on the implementation (mostly style and readability) and also noticed some issues with the Jasmine tests. Could you do a pass through all the Jasmine tests and make sure they make sense, are testing the right things, etc.

I also realized there's a pretty good chance that shape.label.texttemplate won't play nice with this feature at all. I would expect variables x0, x1, y0, y1 to work as expected, but the remaining ones simply don't make any sense when the endpoints are associated with different axes. Can you test out what happens? There should be a decent error case (ignore the variable, perhaps?) rather than a catastrophic failure or showing the wrong information.

@emilykl Thanks for the comments! I tested texttemplate with multi-axis shapes and it doesn't cause an error but the derived values (e.g. width, height, slope, et.c) don't make any sense as you predicted. Raw values (x0, x1, y0, y1) work fine but something like width would be meaningless since we're mixing coordinates from different axes. Should I document this limitation somewhere or maybe throw an error?

Meanwhile, I also modified the code to display labels for non-path shapes since it previously didn't work well with multi-axis references. Also added labels to the image test to confirm that it works.

@alexshoe Thanks to @camdecoster 's work in #7577 , we now have the shape.texttemplatefallback attribute, which is already used in cases where the given variable name is invalid. So I propose we use texttemplatefallback for the derived variables for multi-axis shapes. See the text_on_shapes_texttemplate mock for an example of how this works in practice (%{length} on the rectangle in the upper-right subplot is replaced with - because length is an invalid variable for rectangles).

Good news that raw values work as expected!

Woohoo! Awesome work — excited to see this go live!

🥳 🥳 🥳 Congrats @alexshoe ! 🎉 💃 🪩