I'm glad this topic is winding down, just for the sake of how long it takes to reply! I have to say how grateful I am for you guys to taking the time out to post your thoughtful comments. No matter how you come across, writing this stuff up takes a lot of time, and I have to appreciate someone who puts in that amount of work.
For final clarification.
1. Do all motion controllers run g-code "natively"? No that's ridiculous. Do most motion controllers aimed at the CNC router market run g-code natively? Yes. What does the FabMo controller run? At the lowest level at which it is interpreting human-understandable code, it's g-code, similar to competing controllers.
3,4,5. It's highly probable that you were running some or all of the following in your shop: 1) An old version of FabMo 2) An un-tuned or inadequately adjusted system 3) Prototype hardware. Earlier versions of the software did exhibit a noticeable delay transcoding SBP to g-code, but this delay was not innate to the process of transcoding, it was simply the result of a poorly structured runtime layer that was wasting a lot of time. The delay essentially existed for a silly reason that has now been resolved. There is still a small delay associated with parsing for very large files in FabMo 1.6.x, but that delay is also for a silly reason and will be gone entirely in 1.7.0
For the foreseeable future, the link between the realtime component and the SBC will continue to be USB. Before you cringe at that, know that on the current and future versions of the physical hardware that doesn't mean a USB cable and connectors - it's all on one board, with the USB link being properly shielded and matched, carried over properly balanced, impedance controlled connections between the two processors. It is is also a "real" USB phy, and not the USB->Serial type of jiggerypokery that is seen in ShopBot legacy and some competing controllers, so it is not susceptible to the dreaded "connection issues" that are so prevalent in certain circumstances. There are actually a lot of advantages to using full speed USB here. Bandwidth and robustness being some of them.
I don't know the answer to your rotary axis question for SB3, but for FabMo, the answer is going to depend on the kinematics that are defined for the machine. For now, with the default kinematics that ship, assuming you don't hit any speed limits and you neglect accelerations, that move would execute in ~6.26sec. The reason for this is because if you go by the "NIST Standard" g-code (which is the closest thing g-code has to a standard) the way coordinated moves are computed that include rotary axes is to compute the vectored distance of the rotary axes by themselves, and then to run the linear part of the move at the speed necessary to execute the move in that amount of time.
Re: Shootout.
We're bringing a tool of course, but if you think you're going to "show me" how much more horsepower a 3HP spindle has than a 1HP spindle - I'll tell you. It's 2 more. If the aim is to show me that there are competitors in the marketplace for our products - Surely you know that we realize that?
If you want to have a race-to-the-bottom about pricing on essentially comparable tools, I invite you to sell me that tool you plan to bring at 60% of what a MAX costs, including CAM software. Then support it forever, with free replacement on defective parts, provide me a cost-effective upgrade path when you come up with something new (or find something new that someone else made, in your case), offer training at an unbeatable cost, and run a community forum at your own expense so that people can communicate, collaborate, and complain. Surely you're factoring those costs into your 60% of our price point on the tool?