In particular, since the seed is unrecoverable after the fact, a system that only has the semi-expanded key available might, instead of writing NULL in the seed field, write “NULL”, which the other system then prefers over the semi-expanded key that contains the actual key material, both compromising the system (as “NULL” is very brute-forcable) and potentially losing the actual private key forever. Standards organizations will continue to insist on supporting use cases where people store and pass around semi-expanded private keys, rather than seeds, and cite the performance hit of deriving the semi-expanded key from a seed as a reason to tolerate such behavior.