[Ethereum] Understanding transaction broadcast better

It's important to note that in the context of this question, transactions aren't ever dropped from the blockchain. The blockchain represents transactions that were validated by nodes (locally) and registered as blocks on the blockchain (remotely). Each full node in the Ethereum network possesses its own copy of the blockchain in local memory, which means that when a transaction makes it to one of these nodes for validation, this process is done offline. A transaction can remain pending in a node or never make it to the blockchain for a number of reasons, which can be grouped into four categories.

The first of which, maybe most obviously, is machine failure; the node simply could be corrupted in some form. There are, however, enough nodes validating transactions that the failure of a few is not enough to stop the chain, but widespread machine failure could prevent pending transactions from registering.

The second reason is that the transaction itself is invalid and cannot be validated, or cannot yet be validated. If a transaction is invalid because it's inherently invalid then it will never make it to the chain. But a transaction which "should" be valid may find itself in the mempool of a full node because of a nonce gap, for example. Perhaps multiple transactions were made in rapid succession and the network didn't neatly serialize them or the client generating the transaction is poorly coded and assigned an invalid nonce, resulting in a transaction that made it to a node with a nonce that was higher (or even lower) than the node was expecting. In this case, this transaction will reside in the mempool until another transaction from the same address with the missing nonce makes it to the chain, and then the node will attempt to validate this "out-of-order" transaction. However, if the transaction with the missing nonce never makes it to the chain then this "out-of-order" transaction will reside in the mempool indefinitely until it's purged by the node for no other reason than lack of local memory (disk space). If the node had an infinite amount of memory then it would likely hang onto this transaction forever, but that is certainly not the case.

The third reason is competition. If the network is hot enough, where there are more transactions willing to pay more gas than yours, enough to keep your transaction in a mempool long enough to get it purged (again, for no other reason than lack of disk space on the node itself), then your transaction may never become a block on the chain.

And the fourth reason is the exception to the rule. A core tenet of Ethereum is to "break stuff" and it's certainly possible that future changes to the protocol could jeopardize pending transactions. Ethereum developers are warned at the door to be ready for anything and events in the past, namely the infamous hard fork, reinforce the wisdom of this advice.

But the practical answer to the question is whenever the node runs out of its mempool's allocated disk space. The operative question then becomes: why is the transaction idling in a mempool?

It looks to me as though this is a bit of an optimisation/edge case that is causing some confusion - that the node assumes that the network that you are connected to is functioning normally i.e. that blocks will be mined by rational actors.

Initially I was under the impression that the txpool is where all the pending transactions are stored on a node

This is correct.

...that the pending block is only present when a node is mining (i.e. the block that's being solved for)

This, specifically, is the part where I think the node assumes that it's part of a network that is or will be functioning correctly in the future.

To help clarify, we can run through some scenarios:

1. In the case above: where there are fewer transactions (TXs) than could be expected to fit into a block (based on the gas limit) then it is safe to assume that which ever node goes on to mine the next block will put all of the TXs from the mempool into the block (after all, there's an economic incentive for the miner to maximise their profit by including as many TXs as possible). So the node can make an intelligent guess at what the next block will look like.
2. In the case where there are more TXs in the mempool than would be able to fit into the block, then it's more difficult for predict which TXs will be included in the block (as reordering/modifying the list of TXs impacts the mining of the block), but it's probably safe to assume that any miner will be aiming to include the TXs with the largest fees to maximise their profit.

Could someone explain the difference between these two concepts in the context of pending transactions, the account nonce and pending transaction broadcasting?

To summarise and hopefully answer these questions:

Valid TXs (either created on this node or received from a Peer) will be added to the node's, local mempool until they are included in a block (whether that block is mined by this node or another on the network). At which point the TX are removed from the mempool and included in the block.

Since we can expect that most of the nodes are rational and behaving correctly; it's possible to make an intelligent guess as to which TXs (from the mempool) will be included in the next block.

As an account makes TXs, the account's nonce will increase to enforce the ordering of TXs for that account. Even if the past TXs have not been included in a block, the account can continue to make further valid TXs as long as the nonce is incremented. They can appear in the mempool and could be expected to appear in the next block - depending on gas fees, num TXs in the mempool etc.

New TXs that are submitted on a node will be broadcast to all or a random subset of its peers (depending on how the node is coded). The new, pending block will only be broadcast to a node's peers when it is mined by a mining node.