Most of the complete nodes operate on normal CPUs, which is now basically ineffective for mining. The mining process is managed by specific mining groups. Therefore, for the complete nodes that basically see the same chain of blocks (there may be inconsistencies in the tip if two blocks are extracted at the same time), they have the same set UTXO. This is because the UTXO set is constructed based on the transactions that are included in the blocks. Each time a complete node receives a block, they eliminate the UTXO that consumed the entries in the transactions and add the UTXO that were created in the output. For a mining node it is similar. If they extracted the last block at the same time as the other miner, then the first miner would be building the next block using a different UTXO set than the other miner. However, after one or two blocks when the network converges (they can not generate blocks indefinitely simultaneously) the network would have the same set UTXO.
For mempool, the story is different. Bitcoin transactions are retransmitted in the network with the best effort. Then, it could be the case that some nodes do not see some transactions until they are finally included in the blocks. So yes, there are inconsistencies in the mempool.
How can a node resume mining after the new block is introduced?
As mentioned above, if two blocks are exploited at the same time, some miners would be working in a different version compared to others. The accepted principle is to build on the block that was received first. However, this is not always the case. Then, when a mining node that is still calculating the hashes of the header realizes that a new block is being mined, they realize that they have lost the "run" for that particular block height and they try to explode in the block that was received more recently.