"So the easiest way to set things up is to position all the sprites at 0, 0 (top left of the screen) and just calculate all the coordinates of the various polygons together - that is to say, ey all use a common reference point or origin.
For whatever reason, the culling goes rather haywire, hence why instead of doing this I choose the top left corner (convenient because it is the first in order, and also the top left, ignoring massive distortions)."
So I'm unclear on the above because you mention top-left in both the desired workflow and also in the workaround for culling.
"The fact that the path is an offset is what concerns me.
For a system like this, where each sprite is a face you run into problems almost immediately. Anything but the most simple of 3d representations will require faces using different images. As my code shows (and it didnt show all of it) the difference between being able to specify the corners by pure coordinates, or having to do them via offsets based on the size of the source image is rather drastic - something that will certainly add up on the overhead per face and how many you can throw around."
In our model, each object is local/relative to the parent group, not absolute. Sounds like you want absolute coordinates? Maybe I'm not understanding, but this seems like a big departure from our model (graphics 1.0 and graphics 2.0)
"For the origin method I proposed, the anchor point is also the sprite's position - that is to say I place the sprite at 0, 0 and make the anchor 0, 0 as well. At this point, having spent only a few hours in graphics 2 I must admit I'm not quite following the reason for not allowing direct placement of the corners - my suggestion was that the path, instead of being offsets, would be the actual values of the corners (relative to the anchor and x y pos of the sprite). You could 'easily' make the path be the real values rather than offsets (ie fill them with the width and height of an image when created or you change frame), which would allow for easier and more direct control."
By default, the path is centered around the object's origin (anchor defaults to 0.5,0.5). This is true for polygons as well. If you change, the anchor then the path is re-positioned. So in this case, offsets make the most sense.
Also, the offsets give us the flexibility to do an optimization where we could turn off 2.5D for objects that don't use it. Not everyone uses it.
Sounds like you have a particular workflow in mind. I still don't quite understand it, so hard for me to comment on specifics.
"I understand the difficulties of using real values rather than offsets - it can cause problems if you change the frame of a sprite and the frame is a different size, but in reality what would be the expected result in this case? I think this sort of issue is far more likely to be relevant where people are arbitrarily changing the path and frame of a sprite and want to maintain the path between changes."
Can you give me a simple code snippet that demonstrates how this changes over a series of enterFrames? That would help me understand what's hard about managing offsets.