1) Yes, MultiChain applies the bitcoin transaction rules, but a whole lot more on top. For example, to check that issued assets (represented using metadata in transaction outputs) balance across transaction inputs and outputs. You can start by looking at AcceptMultiChainTransaction()
2) Based on the mining-diversity value, the next miner can be any of those who are permitted. Each possible miner chooses a random time delay close to the target block time, and whoever generates the block first wins. If there's a fork, it's resolved in exactly the same way as bitcoin – whichever fork is extended first wins. Note that in addition there's a mining-turnover parameter which allows forks to be minimized, by allowing the set of active miners to automatically self-select and stay consistent, unless/until one fails at which point it's random again. But this is not a consensus rule – just a request from nodes about how to behave.
3) First, depend on the mining-diversity parameter, it could be more than 51% required to reverse the chain. Second, if you want to perform finalization, you can use the lockblock parameter (also available via setruntimeparam) to lock down a particular history. For now you need to manage this yourself at the application level, but we're working on improving that. Nonetheless, you should also consider the fact that, in any consensus system, you run this kind of risk. No matter what consensus algorithm you use, a majority of nodes can decide that a different history is the "truth", and therefore rewrite history, and there is no objective way to contradict them.