-snipped-
that doesn't require breaking backward compatibility with legacy nodes. the fork just needs to add new rules to lock or destroy ECDSA-secured coins. of course, that would make legacy nodes useless---but not incompatible---so it would still be a soft fork. (not that it matters)
it is not about backward compatibility, it is about old nodes not being forward compatible and addition of new rules.
forward and backward compatibility are two sides of the same coin.
old nodes would be forward compatible. they could still process eg OP_LAMPORT transactions (though they would not be able to fully understand them), enforce their network consensus rules, forward blocks to peers. they just wouldn't be able to secure bitcoins (outputs sent to them would be destroyed) nor could they broadcast transactions that would be accepted by the network.
we first have to add a new OP code for the new signatures. and we have to use the new signature scheme that everyone accepts (reaching consensus) and since both of these are new rules that we would be adding they require hard fork.
https://en.bitcoin.it/wiki/SoftforkNew transaction types can often be added as softforks, requiring only that the participants (sender and receiver) and miners understand the new transaction type. This is done by having the new transaction appear to older clients as a "pay-to-anybody" transaction (of a special form), and getting the miners to agree to reject blocks including these transaction unless the transaction validates under the new rules. This is how pay to script hash and Segregated Witness were added to Bitcoin.