There have been a few new sighash types proposed.
- SIGHASH_NORMALIZED : Use a 'normalized' TXID in the inputs when serializing for signing. This normalized transaction id is calculated by removing the scriptSigs of the transaction that you are spending from before serializing.
- SIGHASH_NOINPUT : Just remove TXIDs from the inputs entirely. Useful for thwarting malleability, but allows funds sent to that same scriptPubKey again to be stolen, so you would only sign an input with this if you are sure you are never going to use that scriptPubKey again.
- SIGHASH_WITHINPUTVALUE : Include the input's value when replacing the scriptSig with the previous scriptPubKey, so signers can prove knowledge of exactly what they are giving away (useful for hardware wallets).
AFAIK, however, if an unidentified sighash flag is used, then the standard client treats it like SIGHASH_ALL (source). Isn't introducing a new sighash flag a hard fork, then? The sources linked to above give conflicting statements on whether new sighash flags require a hard or soft fork.