It's different.
From reading your question, I got the impression that you're thinking about this from the perspective of a cluster of computers that know and trust each other. There is some misuse of terms that may make it difficult for you to interpret documentation and explanations. If I may, I'll try to sort a few things out without getting too technical about the details.
First thing is Ethereum is designed for a hostile environment in which up to 49.9% of the nodes may be not merely non-functional (crashed), but overtly hostile and deliberately sewing confusion in the network. It is not optimized for performance. The focus is on resilience.
The txpool is subjective from every perspective. It can be understood as the transactions a node (miner, if they want to be) is aware of that haven't been mined into a block. Transactions propagate through gossip, so eventually all nodes will be aware of all proposed transactions. In practice, this is never the case because of network latency. This is why the list is subjective from the perspective of every node.
Transactions that are malformed will not be propagated, otherwise that would be a denial of service attack vector. Transactions don't need to have any chance of success to propagate, for example, attempting to double-spend. The system imposes a financial cost to such exploits in the form of transaction fees (gas) that will be burned in the case of failed transaction. i.e. It is expensive to flood the network with useless transactions.
Another concern is the order of the transactions. Every (full) node processes transactions and forms its own conclusion about the network state. In this context, "state" means balances and data stored in contracts. But, in order to reach consensus about state, the nodes first need to reach consensus about the transaction order. This important function is addressed by miners and the mining process.
Miners have latitude about which transactions to include in a block. There are all sorts of economic considerations. Generally, the gas price is the sender's bid for priority. While it isn't the only consideration, miners are more likely to include transactions with a high gas price, especially during periods of network congestion.
Which miner should perform the task?
In the case of a network where all the participants know and trust each other, something like a round-robin or fault-tolerant scheme would work. This is common in the world of private blockchains. A public blockchain needs another solution. Consider that reordering transactions can have non-trivial financial consequences. All sorts of angles are possible, so a public blockchain needs another solution to prevent a selfish miner from gaining outsized influence over network happenings.
This is where Proof-of-Work comes in. The puzzle (lottery) proves that considerable work went into "searching" for a magic number that will make the transaction block (an ordered set of transactions) work according to the network rules including difficulty.
When a successful miner "finds" a block (with a magic number, the nonce) they broadcast to the network. Other nodes will recognize the validity of the "solution" and accept the block of transactions as a de facto agreed transaction order. That makes it possible for each node to process the transactions in the same order as everyone else and reach the same conclusions about the impact of the transactions. In other words, everyone agrees on the results because everyone agrees on the inputs.
It is common for multiple miners to "find" a block more or less at the same time and without knowledge that another miner also found a block due to network latency. In that case there are two possible interpretations and after some gossip, everyone will know. In that case, the "heaviest" fork wins. The other equally valid block gets some reward and still helps secure the consensus as an "ommer" a.k.a. "uncle". Those are the keywords if you want to dig deeper into mining.
In the end, the blockchain is a well-ordered series of blocks and each block is a well-ordered series of transactions. The transaction pool is a queue-like construct that is different on every node.
Hope it helps.
