If you receive a transaction on your node, and it is confirmed, you will regard it as a good one. The coin being spent may not exist on the other chain, or there may be another transaction on the other chain spending it differently. So you will lose coins, and can easily be scammed.
That's not what I'd call "losing coins because you run a node". The coins are what they are. You may be ILL-INFORMED about what's the status of a coin, yes. But as long as you don't take any action, the fact that you run a node or not doesn't make you "lose coins".
BTW, of course, if you have a node that looks at chain A, this is not saying anything of what happens on chain B. If you run a litecoin node, it doesn't tell you anything of what happens on the bitcoin block chain either. In fact, it isn't even your *node* that matters. What matters are the chain(s) that are existing out there, and which can be found on the miner pool nodes that make them. So if you take a light wallet, and you connect that light wallet to a miner pool node that makes the chain of your choice, whatever it is, you'll be all right, and get the right information. A "right" full node can only copy it at best.
And as soon as you spend them, you may be victim to an attack where someone copy your transaction to the other chain, and receive your coins on both chains.
That's evident that if the chains have identical signature schemes, and you didn't do anything to split them, of course a valid transaction on chain A will also be a valid transaction on chain B, the famous "replay attack". The thing to do, is that ideally, the one forking off should modify something in the signature (hard fork !) so that this is automatically solved (a good signature on one scheme will not be a good signature on the other) ; or you should mix in yourself newly mined dust on one of the two prongs. Otherwise, it is normal that any signature on one chain will be copied over to the other chain.
But all this has nothing to do with "running the right node". You should construct the right transaction, and that's done with a wallet. A light wallet can perfectly well make a good transaction.
Unless double-spending protection is in place before the chain splits. This was not the case with ethereum, and many lost their coins on one of the chains due to this vulnerability. None of the bit-altcoins address this problem properly in their attempted chain splits, and this is why exchanges won't adopt them, even as altcoins.
As I said, the best solution to handle this is by using some mined dust on each of the prongs, to make transactions that are only valid on one branch. But ideally, those forking off from the original chain should ideally make something incompatible in the signature scheme (hence, making a hard fork).
If it was simple to change the hard economic consensus parameters, like block size, inflation rate, time between blocks, POW algorithm etc, it would have happened several times already. It doesn't, because people want bitcoin to be a secure store of value.
It doesn't, simply because of the mechanism of immutability, which, however, can break down if centralization occurs and there's a collusion of more than 50% of the consensus (= hash) power over a change.
> 50% of hashpower can only restrict activity by refusing to mine certain transactions. They can not change the consensus. If they produce invalid blocks, the hashpower is worthless. Nodes will just throw their blocks away.
More than just restrict activity. ANY soft fork is automatically imposed by a >50% hash rate collusion over the soft fork. If tomorrow, >50% of miner nodes decide to impose segwit, then segwit will be. Other miners have no option. They will get orphaned all the time according to their own rules. Because all nodes will accept segwit blocks like "legacy nodes", including the non-segwit miners.
Any soft fork is imposed by >51% hash rate collusion.
Yes, blacklisting addresses is also a soft fork, and is also imposed by >51% hash rate collusion over that black list.
A hard fork is a whole different affair: you make two coins, and users happen to possess both of them. Up to them to use both of them, by running their respective wallets (and eventually, their respective nodes).