This is what I was trying to do, but offsetting the main body bone and rotating it worked better than translation would have anyways:

 Loading Image

I don't have any animations currently that I want to separate x and y, but while I think adding an x-only bone and y-only bone would definitely work, I also feel like I would be adding those bones for no reason other than to control the path from A to B.

A simple idea would be to make something like a bouncing ball. Put a translation key at every bounce and peak, X would be rather constant, and controlling Y would allow you to give the bounce some curve, vs having to add a bunch of keys to round it out.

I like the suggestions Pharan! I had thought of the single bone with distance from the object to move something in a circle, but I didn't think of making separate bones for x and y. I suppose since it's not common to need to separate the two, I'll just give that a try whenever I want to give them separate curves.

Also, I wasn't so much suggesting x and y permanently be separate, but instead just having some kind of toggle switch that allows you to separate them. It would be equivalent to making translate X and translate Y more like rotation, each having their own value when the toggle is active for a selected bone, like this:
 Loading Image

I just noticed you have the github up to submit issues, so I'll start using that to let you know anything I come across.

One thing that would be a good addition is the ability to set X and Y graphs separately (mostly specific to translate). Currently, because they work together, the motion from key A to key B is linear, and the graph just decides how fast the bone will move along the path. Setting X and Y graphs separately however would allow you to move something in a circular motion, or change the way something gets from key A to B. There are other ways you could accomplish this, but just having a button to separate the two would be the easiest in my opinion (which honestly, not having seen the code, doesn't really mean much :p )

Another suggestion would be to allow more points on the graph besides the start and end point. This would allow for more complex movement between two points. This isn't changing much though, because this would be relatively equivalent to using a bunch of keys instead.

Just small things I've noticed while using the program, and wished I could do.

Another issue: In the export menu, selecting GIF and then clicking the background color box crashes spine.

Also, would you prefer me to email contact@esotericsoftware.com, or posting here on the forum? I just noticed on the little crash screen you say to email you, so if that would be easier I'll send any bugs I find to the email instead.

One more crash, involving undo:

Select a bone, and set current frame to somewhere without keys. Add a rotate key, which adds two green blocks (one in the animations row, one in the rotate row) and immediately undo. This only gets rid of the rotate block, and clicking the remaining green animation block crashes spine.

Another way to do this is add a rotate and then a translation key, which gives you two white blocks (one in the animations row, one in the bones row) a green block in the rotate row, and a blue block in the translation row. Undo the translation key, and you're left with two white blocks and a green block. Clicking either of the white blocks crashes the program.

I believe this is the same issue mentioned in this topic: http://www.esotericsoftware.com/forum/viewtopic.php?f=3&t=718. This crash still happens on the most recent update, 1.3.29, as well. I'll keep testing things and let you know if I find anything, keep up the good work!

Got another one for you, this is a little worse, it crashes the program:

Start with a single bone selected. Then rotate the bone, and click the key for rotation. On the dopesheet there will be 2 green boxes. Then rotate the bone again, and then click the orange key. This time, the dopesheet will have 2 green boxes and a white box (the white box doesn't belong). Clicking the white box will then crash the program. This can be reproduced with any type of keyframe (rotation, scale, translation etc), and happens using both the 'k' key and clicking the key buttons.

Hope this helps!

Ahhh, right click, should have tried that...

Another small bug, still nothing major:

If you set the current frame to anything except 0, and then zoom in, it will zoom in on the current frame but there is no scroll bar to get the view back to 0. The only ways to get the view back are to either zoom out of the dopesheet again, or drag the current frame left. This also acts wrong if you set the current frame to the last frame and press the little auto-adjust zoom button, but the scroll bar appears and you can click it to correct the visible frames.

So for example, if you have a 40 frame animation, and set the current frame to 40 (your last frame), and zoom in so only 40 frames are visible, then you will only be able to see frames 20 through 60. There won't be a scroll bar because the total visible frames >= number of frames in the animation, and you can't look at earlier frames without changing the current frame.

Hope this makes sense!