1. how do they plan to prevent someone from flooding the system with (matched) orders and not following through with the actual coin transfers?
Once funds have been transferred under the distributed control of reputed multisig signers, orders must be validated by enough signers to transfer funds plus two backup signers to be regarded as valid by the protocol. The potential exploit of placing two orders simultaneously to consume the same funds is really just a double spend. This problem has been famously solved by Bitcoin, and we will use the exact same proven solution in B&C Exchange. Orders must have a certain number of confirmations (this number is dynamically configurable through shareholder voting) to ensure this type of double spend has not occurred.
2. is reputation based on votes by the coin holders the best one in your opinion?
Yes. There are schemes I considered that reward signers for actual work or signings but these are all significantly more complicated and subject to various kinds of gaming. Simplicity is really compelling in a consensus protocol. It is expected some shareholders will be tempted to upvote their own address to receive a reward without performing any work. Reputed multisig signers will need to make public appeals to the community to explain why they should selected to sign. This means that any mystery addresses that are receiving upvotes should be downvoted by all other shareholders. A mystery address receiving its first malicious upvotes will not be trusted with signing because only top rated addresses can do that (the number of top rated signers permitted is also dynamically configured via shareholder voting), and it will take quite a bit of time to get to the top. While this is quite a bit to keep up with, it is expected that most shareholders will use a data feed to delegate their vote to someone who is watching closely that they choose to trust. Data feeds have already proven to work well in Nu. Shareholders have proven incredibly responsive in dealing with emerging conditions in the Nu network.
3. What are your reasons to have a separate token for transaction fees. why not the native token in the system?
Actually, using BlockShares was my initial choice in my first draft, so I can relate to that inclination. Tom Joad suggested using a separate token. The main advantage to this is stable value, so that the cost of transactions will be stable even as the BlockShare price experiences volatility. This is very easy to implement because within the code base BlockCredits equate to NuBits while BlockShares equate to NuShares. Almost all the needed code is already there.