1. No, TNet doesn't do any buffering with UDP packets. If you want them to arrive in a specific order, stick to TCP.
2. I am not sure what you're referring to but I don't do missing step interpolation. What TNet suggests doing by default is separating your renderer from your rigidbody. I always have renderer smoothly following the rigidbody. In Windward's case I sync the ship positions only once every ~2-4 seconds, and in-between I just do regular physics-based movement. The values that cause the movement (basically user input) are sync'd much more frequently than that, resulting in each client performing their interpolation using the latest data available and correcting the positions every so often. Since the rigidbody is also separate from the renderer, any corrections are done using interpolation, smoothly adjusting the position to where it should be after the correction packet arrives.
3. If you're smart about it, and don't simply brute-force all that data several times per second for every single object, then sure. In Windward there are usually ~10 ships, each capable of firing ~20 cannonballs per second, resulting in 10*20=200 active physics objects at a given time. I handle that by not even bothering to sync the cannonballs. Each one is created from an RFC packet rather than TNManager.Create, so they are all basically local to the user. Each cannonball's lifetime is only 2 seconds at most, so it's not noticeable that they are not synchronized beyond the first creation.
4. Again, be smart about it and you will be fine. That said, Amazon EC2 may not be your best choice for a real-time game. TNet doesn't do compression. The AutoSync component will check to see if the value has changed since the last time you tried to send it, but I don't recommend using AutoSync scripts for anything other than prototyping. It's always easier to optimize your own RFCs.
5. Same as #1: TNet's primary form of communication is through TCP, not UDP -- and TCP is always ordered and doesn't need this. UDP packets are used if you use tno.SendQuickly, and they are not ordered. It's very rare for packets to arrive out of order in this state of age. UDP packets generally arrive, or don't. I suggest using UDP packets only for things like frequent state updates that you do several times per second, where each state gets overwritten by the following. Consequently, I stick to TCP myself in Windward.
6. Unity 4 would require a Pro license on mobile. WP8 doesn't support sockets the same way so TNet won't work. iOS/Android work as expected, and I have a mobile game using TNet called Starlink.
