I could write a really huge response to this. Our first Xpression AR event was last January, and we had a lot of problems with it - some of them growing pains/learning curve on our side, some of them were just some software related nonsense. Our second project in February was a fiasco that was almost (but not quite) entirely related to work flow and last minute graphics.
I guess the question is if you use Xpression for AR, are you using Ross's UX for interfacing and camera tracking. That's where most of our issues come in. A lot of our issues work work-flow related; an artist creates the graphics, and I script them. We tried having a master project that I worked on while the artist worked on a parallel project that we would copy templates from. That screws up your textures and materials in ways I don't even want to talk about, so it's one person at a time on a project. We use subversion to push/pull changes to the project, and coordinate who will have the "working" version that can be updated. Subversion is sort of like Xpression's project management, but we can include things like spreadsheets and currently non-used textures in our updating.... every file in the project folder.
UX is essentially written to take one template live and it works more easily if all your virtual objects are in that one template, then you use UX as an interface to turn them on/off and position them as needed. In theory that's great. In practice we feel like it's better to separate objects out into separate scenes to make them easier to work on, so in our current production every time we're switching which virtual we want to deal with, I have to go to UX's driver interface and select a different scene. There will likely come a time when we want two things at once, and I will be screwed.
I've experienced quite a few issues I'd consider bugs - it's not always easy to tell if it's UX or Xpression, or the combination. It's very difficult to work on a project that has been loaded by UX. I recently discovered that if I add objects (even if that means I just group several existing objects and, in the process, create a new group object), that my UX interface may stop referencing the correct objects. If I try to script something - like taking a team tricode and pulling up team colors to set an object with, my scripts don't seem to want to run. After hours trying to figure out why my script wasn't working, I figured out that if I shut everything down and restart, it will start working. Animations never seem to work right for me. I had to write GPI triggers to get the animation to work, and even in that code I couldn't just play the animation, I had to be very explicit in what I was doing.
A lot of issues can be resolved with a good work flow, but that's simply not always tenable in live situations. I often feel like things just stop working in UX, and end up going back to the Xpression UI do to things like change textures/materials, and that doing things like that make it more susceptible to crashing.
One issue is that our current version of UX is written against Xpression API for 6.5. I have 6.7, and I cannot be sure if some of our issues are related to that, and I would like to upgrade to 7.1 but am deathly afraid that UX won't work at all.
I want to express that I'm coming from ORAD, and if I have a year of learning how to work around problems in Ross, that's far better than the five I spent trying to make ORAD do what I wanted. I am a programmer, so I am comfortable writing scripts around issues that crop up. Your mileage may vary, as they say.
#XPression