Here's the response I got from Evtim:
The path is really really tiny (scaleX & scaleY are 12500 to scale the path to up to ~ 80 x 30).
One thing that I noticed is that when we try to determine the bounds of the path internally, since we rely on the Player method getBounds() it seems that we're getting (0,0). This is because the path is really really small and the Player rounds down to 0. So I hacked this up to make sure we get the correct bounds, and we render at internal scale (1,1) after which we apply the scaleX & scaleY 12500 to the display object of the path - but the result seems to be the same. It is possible that the really tiny numbers are throwing off the Player, as Player as far as I know uses fixed point limited precision math to rasterize (didn't they tell us about some 8k limit?).
It is possible that we could look into some sort of work-around, basically pre-multiplying with the scaleX & scaleY before we pass in to the Player. We should log a bug and investigate and weigh the options. The work-around for the mean time is pre-multiply the path's coordinates instead of using tiny numbers with huge scales.
The path for me worked ok, when I manually adjusted the coordinates and reduced the scale to 1.25. Another thing that I noticed is the path is not constrained to the skin, perhaps left, right, top, bottom or %width %height are appropriate (the path seems to spill out of the button otherwise).
Is it OK to post possible bugs here in general discussion or is it preferred that I enter them in JIRA?
I think it would be preferrable to file the bug report in JIRA (http://bugs.adobe.com/flex/) and attach a simple, reproducable test case (if possible). That way we can make sure we track the issue correctly and it doesn't slip through the cracks.
Flex SDK Team | Adobe Systems Inc