As I said in the previous post, the underlying geometry is a soup of triangles with local coordinates: (0, 0), (1, 0), (0, 1). I take advantage of the fact that these will also happen to be the texture coordinates. In the mesh code, in impl/unbatched.lua, you'll see this line:
return corner + pos - CoronaTexCoord;
CoronaTexCoord will match one of the expected local coordinates. It's subtracted from pos (Corona's calculated position for the corner) since we don't actually care about this little local triangle: we only needed something that wasn't degenerate. So all three corners will map to the content coordinate of (0, 0), and then corner is added to that.
Scaling will slightly break this assumption. It should already be baked into pos (are the meshes scaling, but wrongly?), so you'd need to scale the correction as well as the corner's contribution. Something like:
return pos + (corner - CoronaTexCoord) * scale;
There's still some unused space in the mesh data structure, so this might be possible to hack in. My thinking is, in either Populate() or ResolveIndices() in that same file, you could sneak in a little dummy rect:
mesh.dummy = display.newRect(mesh, 0, 0, 1, 1)
mesh.isVisible = false
then, in UpdateUV(), before the loop, check its size:
local w, h = mesh.dummy.contentWidth, mesh.dummy.contentHeight
and in the loop itself replace the lines
for i = 7, 9 do
uvs[i] = 0
uvs, uvs, uvs = w, h, 0
to spam its scaling to all triangles. I believe the uvs are constantly updated so this should stay in sync.
(I used a 3x3 matrix to be able to randomly access the corners' three coordinates but had no use for the third column.)
Finally, amend that line earlier to:
return pos + (corner - CoronaTexCoord) * vec2(u_UserData3, u_UserData3);
and cross your fingers.
This is all off the cuff (it's a bit late here) but seems at least plausible to me. In theory a similar idea could be used to effect rotations, but that's left as an exercise for the reader.