I've been thinking on restrictions around concurrency of smart contracts given the deterministic nature of the EUTXO model, and I've had trouble finding an answer to how transactions are prioritized for a block in the case where multiple valid transactions exist visible to a node redeeming a single UTXO. Is this left to the slot leader to decide?
This question also leads into another question I have, which is: Is network spam somehow a viable concurrency model since fees are not charged for simple validation failure? Like say you change the Uniswap implementation to allow for multiple liquidity pools of a given trading pair (thus multiple corresponding UTXOs) Would it be viable to submit multiple transactions redeeming overlapping UTXO's in the hope that only one transaction would go through?
Maybe this is still being thought about and maybe this question is ultimately silly, but I was hoping to hone in my thinking around this a bit.