We don't have to get into a debate about it, but I humbly disagree. 
The difference is that Adobe has a massive dev team working closely with the huge audience that uses it, so the amount of new features and improvement is at a pace that's in a different world than what a team of one or two can accomplish. So the chances that a feature that's needed by the community is much higher. 
Like I said, I hear you that working in another person's live source code is hard, but we're an experienced team that's worked on and contributed back to many different game engines and tools that have source licenses. We know it's hard - it's absolutely a pain to build inside of someone else's codebase, but increasing an artist's workflow by 5% or even 1% over the lifecycle of the product / company is totally worth it. We disagree on that value, and that's ok. Just a bummer for us that your opinion that we wouldn't want to be working on the editor prevents us from working to add that value to our team and to Spine.
Thanks for the suggestion for a hacked solution for the runtime - it's the approach we were planning on taking if we end up landing on Spine. It is very hacked on and doesn't give the artist the ability to iterate on their work in the editor (as you mentioned). Honestly it makes me just want to build another layer inside of Unity that does and visualizes that work, forcing the artist into a clunky workflow if they want to see their work, and decreases their ability to be awesome. That sucks.
Looking forward to v3 and will be looking into alternatives in the meantime. Thanks for the help.
