Yes. The simple idea of
1) building a higher-order (vector-valued) Function
2) setting its values appropriately
3) setting mesh.coordinates = new_coordinates
does _not_ "just work", because UFL manages to sniff the function space of the something of the domain [you get the idea] that the coordinate field Function was built on. This, of course, is still P1/Q1. Therefore the generated C code is written as if the coordinate field is still lowest-order.
I've recently discovered that simply doing mesh.coordinates = new_coordinates seems to break many things, including Firedrake par_loops and mixed problems. I understand Miklós has made significant progress on a more robust solution.