Changing the behavior of an op-code could mean that old (unupgraded) nodes interpret a transaction with that op-code differently than new (upgraded) nodes. If nodes interpret transactions in two different ways, this may cause the network to split as some nodes accept a block as valid while others reject it as invalid. We call such a breaking change in the protocol rules a “hard fork”.
Since we cannot go back and change how old software behaves and cannot force users to upgrade their software, we are careful to introduce changes in a forward-compatible manner. If we introduce new behavior, then in a way that makes the old nodes accept it, even when old nodes cannot fully validate the underlying script. We call this style of protocol rule upgrade a “soft fork”.
Changing OP_CHECKMULTISIG to pop one fewer element off the stack would be a hard fork. Even if a majority of the nodes was upgraded when such a rule took effect, the first transaction that makes use of the new rule would cause all old nodes to stop processing the most-work chain, forking the old nodes off the network.
