This decision was rooted in the aim for maximum interoperability among various applications that use BIP39. By ensuring a unified method of sharing entropy through a single seed, thousands of BIP39 applications can maintain complete interoperability without the complications that would arise from implementing different key stretching methods.

Rusnak highlighted that having a version could have led to significant drawbacks. For instance, hardware wallets are limited in their ability to use memory or CPU intensive key stretching methods like Argon2. Introducing versions might also pave the way for proprietary key stretching algorithms, which could further fragment compatibility. The design philosophy behind BIP39 was to establish it as a universal base layer for entropy sharing, with complexities being handled by higher-level protocols.

Furthermore, Rusnak argued against encoding derivation paths into the versioning system. Doing so would reduce the future-proof nature of seeds since new standards would necessitate creating and backing up new seeds for each evolution in technology, such as Segwit or Taproot. This requirement would lead to users managing multiple seeds for different applications—such as Nostr, Lightning, Cashu, Ark—which could result in disorganized and unreliable backups. In contrast, the BIP39 approach allows a single seed to remain applicable across various applications and technological updates, simplifying the user experience and fostering robust backup practices.