Thanks for the additional insight!
Is my whole overview a better reflection now of what happens at this "block appending" stage? I've tried to take into consideration all the different feedback I received.

Thanks for all your helpful and detailed replies! Having considered your comments and thought about it all some more, I've come up with the following updated overview. The bits in bold italics are additional assumptions I've made about the mempool, and definitely need reviewing...

Further feedback and corrections, gratefully received!

1. When a new block has been successfully mined, it is propagated throughout the network for nodes to validate.

2. When a node receives a newly mined block, it first validates the whole block (e.g. hash of block header < difficulty target; hash of previous block = hash of block which node wants to build on, etc.) If it fails, the block is immediately rejected. If it is validated, the node immediately propogates the block to other nodes in the network for them to validate, and then procedes to validate the block's individual transactions (all inputs are valid UTXOs; sum of outputs < or = sum of inputs, etc.). If it passes both of these validation steps, the block is accepted by the node, added to its version of the blockchain, and the block's transactions removed from the node's mempool.

3. If the same node subsequently receives a valid competing block (with the same parent as the one added in 2. above), the initially-added block remains at the tip of the active chain, but the valid competing block is also kept, marked stale, but still monitored. If the node then receives a valid block which links cryptographically to the stale block, the block at the tip of what was the active chain becomes stale, and the now longer branch becomes the active chain instead.

4. Stale blocks are not discarded because they are still valid blocks with an ancestor within the active chain. Their transactions, however, remain in the node's mempool, or are returned to the mempool if previously removed. If a stale block becomes part of the active chain again, its transactions will be removed from the node's mempool.

5. If a node receives a valid block which links cryptographically to a stale block, and this happens to create a chain (B) with a higher total difficulty, but which is still shorter than the active chain (A) in terms of number of blocks, then chain B will become the active chain, and all of the blocks in chain A after it splits (although not discarded) will now become stale.

Is the following an accurate summary of what happens?
(I've also included some questions)

1. When a new block has been successfully mined, it is propagated throughout the network for nodes to validate.

2. When a node receives a newly mined block, it:

• validates all the transactions contained in the block by cross-checking them against its version of the blockchain;
• validates the whole block by running the PoW algorithm to check that adding the block to its version of the blockchain generates the same hash value.

If either of the above validation steps fail, then the block is rejected by the node. If both steps pass, then the block is added to the node's own version of the blockchain, and propagated to other nodes in the network for them to validate.

3. If the same node subsequently receives a valid competing block (to the one just validated and added in 2. above), will it immediately replace the previously added block (which would then become a stale block) if the competing block has a higher difficulty? Or will it also add the valid competing block and temporarily maintain a split version of the blockchain until it receives another valid block which links cryptographically to one of the two branches, discarding at this point the block on the "shorter" branch?

4. Each node also continuously compares its growing version of the blockchain with the versions maintained by the other nodes it communicates with.
If a node discovers a version that is "longer" (in terms of total difficulty, not necessarily number of blocks), does the protocol require it to automatically add the other version's additional, or different, block(s), and to discard any blocks included in its own version which are excluded from the other (which would then become stale blocks)? Or does each node decide for itself if and when to amend its own version in this way? For example, could it decide to wait to make such amendments until a certain number of blocks have been added to the other node's "different" block(s)?
Does this have anything to do with the process of synching?

I'd really appreciate some more clarity on these points... I've been tying myself up in knots trying to reason it all through...