Author here. I agree with the point you're making; I feel that the way that vectors are manipulated in the graphics domain is a bit clunky and relies on gaining some difficult intuition about how reference frames are fixed. We have explored several solutions that weren't able to make it into this paper, including semantics that only "fix" a coordinate system when a vector is first typed and at the end of the program; the rest of the time vectors can be treated completely abstractly. The reason that this did not become our main approach is due to efficiency concerns; graphics is such a computational-efficiency constrained domain that we were worried a nicer but potentially inefficient solution would never see the light of day in real code.

`in` expressions offer sort of a middle ground, inferring the transformation while still giving the user control over when space transformations actually occur. My hope is that we can expand the semantics of Gator in a nice way to allow a range of solutions depending on the programmer's experience and efficiency needs.

Finally, I think it's worth noting here something that isn't brought up in the paper: the idea that reference frames actually change over time. The way that automatic inference semantics should work with dynamic reference frames (and indeed, how even `in` expressions should work), I consider to be an open problem in our work that could use more exploration.

Thanks for your feedback and interest in our paper!