You might face this question if using hierarchical deterministic crypto wallets (technically called BIP32 compatible wallets).

As you know these wallets generate your addresses from a common seed and each address corresponds to a given a path of calculation taken from that seed.

There are many implementations of the BIP32 specification across different languages and most wallets support importing and exporting the seed (in the form of a mnemonic). This should also ensure that the implementations remain compatible, because errors would be very apparent during transition between them.

This is not always the case though and bugs can remain hidden for a long while.

Recently some users of MetaMask and Ethereum TestRPC managed to find a case where two different BIP32 implementations disagree. MetaMask uses consensys/eth-lightwallet, while TestRPC uses ethereumjs/ethereumjs-wallet. These in turn depend on bitpay/bitcore-lib and cryptocoinjs/hdkey, respectively.

Don’t worry, there is no risk of losing keys or money as long as you use the same implementation.

Using a different implementation will not cause the loss of keys, only they will not be available on that wallet. Moving back to another one having the issue, will make those keys available again.

I would encourage wallet providers (using bitcore-lib or other affected implementations) to fix their implementation to match BIP32 and offer a way to their users to derive the non-compliant addresses as well.